$ grep long */*.h
minus comments, etc yields several questions about whether some
values should use Py_ssize_t rather than C longs. In particular:
* hash values
Include/abstract.h: long PyObject_Hash(PyObject *o); // also in object.h
Include/object.h:typedef long (*hashfunc)(PyObject *);
Here's the int questions. The entire list is too big to post (50k),
so it's here:
http://www.python.org/neal/header-ints
Should the following values be ints (limited to 2G)?
* dict counts (ma_fill, ma_used, ma_mask)
* line #s and column #s
* AST (asdl.h) sequences
* recursion limit
*
Is there still time for new feature requests in Python 2.5?
I am missing a isgenerator function in the inspect module. Right now
I am using
def isgenerator(func):
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
Michele Simionato
Neal Norwitz wrote:
Should the following values be ints (limited to 2G)?
* line #s and column #s
Anyone with a source file more than 2G lines long
or 2G chars wide deserves whatever they get. :-)
Not-investing-in-a-1.3e10-pixel-wide-screen-any-time-soon-ly,
Greg
On May 28, 2006, at 5:34 PM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote: On May 28, 2006, at 4:31 AM, Thomas Wouters wrote: I'm seeing a dubious failure of test_gzip and test_tarfile on my AMD64 machine. It's triggered by the recent struct changes, but I'd say it's
On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote:
Well, the behavior change is in response to a bug http://python.org/sf/1229380.If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is the only way to find them :)
Feel free to comment how
On 5/29/06, Neal Norwitz [EMAIL PROTECTED] wrote:
* ints:Include/intobject.h:long ob_ival;I considered asking about this before, as it would give '64-bit power' to Win64 integers. It's a rather big change, though (lots of code assumes PyInts fit in signed longs, which would be untrue then.)
On
On May 29, 2006, at 3:14 AM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote: Well, the behavior change is in response to a bug http://python.org/sf/1229380. If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is the
On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote:
A compromise is to do proper range checking as a warning, and do the modulo math anyway... but is that what we really want?I don't know about the rest of 'us', but that's what I want, yes: backward compatibility, and a warning to tell people to fix
On Sun, May 28, 2006, Roger Miller wrote:
I am a recent subscriber to this list. A couple of months ago
I downloaded the Python source out of curiosity, then decided
to see if I could scratch a couple of small itches.
Please post your patches to SourceForge, then post links back to the
list.
Aahz wrote:
On Sun, May 28, 2006, Roger Miller wrote:
I am a recent subscriber to this list. A couple of months ago
I downloaded the Python source out of curiosity, then decided
to see if I could scratch a couple of small itches.
+1 on the change, the error messages that report the
Ok, here comes the first half of April. Again, please let me know if
you have any comments or corrections (and thanks to those who already
got back to me on the last one). I'm gonna try to keep these coming
over the next week or so until I'm all caught up.
=
Announcements
On May 27, 2006, at 04:59, Alex Martelli wrote:
I believe it's: kqueue on FreeBSD (for recent-enough versions
thereof), otherwise epoll where available and nonbuggy, otherwise
poll ditto, otherwise select -- that's roughly what Twisted uses for
kqueue is not always faster. It depends on
Hi all,
I've finally come around to writing a patch that stops dict lookup from
eating all exceptions that occur during lookup, like rare bugs in user
__eq__() methods. After another 2-hours long debugging session that
turned out to be caused by that, I had a lot of motivation.
[Neal Norwitz]
* ints: Include/intobject.h:long ob_ival;
[Thomas Wouters]
I considered asking about this before, as it would give '64-bit power' to
Win64 integers. It's a rather big change, though (lots of code assumes
PyInts fit in signed longs, which would be untrue then.)
I expect
[Neal Norwitz]
* hash values
Include/abstract.h: long PyObject_Hash(PyObject *o); // also in object.h
Include/object.h:typedef long (*hashfunc)(PyObject *);
We should leave these alone for now. There's no real connection
between the width of a hash value and the number of elements in a
[Thomas Wouters]
...
Perhaps more people could chime in? Am I being too anal about backward
compatibility here?
Yes and no ;-) Backward compatibility _is_ important, but there seems
no way to know in this case whether struct's range-checking sloppiness
was accidental or deliberate. Having
Thomas Wouters [EMAIL PROTECTED] wrote:
On 5/29/06, Bob Ippolito [EMAIL PROTECTED] wrote:
A compromise is to do proper range checking as a warning, and do the
modulo math anyway... but is that what we really want?
I don't know about the rest of 'us', but that's what I want, yes:
On 5/29/06, Tim Peters [EMAIL PROTECTED] wrote:
[Thomas Wouters]
...
Perhaps more people could chime in? Am I being too anal about backward
compatibility here?
Yes and no ;-) Backward compatibility _is_ important, but there seems
no way to know in this case whether struct's
From: Armin Rigo [EMAIL PROTECTED]
I've finally come around to writing a patch that stops dict lookup from
eating all exceptions that occur during lookup, like rare bugs in user
__eq__() methods.
Is there a performance impact?
Raymond
___
[Guido]
...
It's really only a practical concern for 32-bit values on 32-bit
machines, where reasonable people can disagree over whether 0x
is -1 or 4294967295.
Then maybe we should only let that one slide 0.5 wink.
...
[Tim]
So, in all, I'm 95% sure 2.4's behavior is buggy, but
On 5/29/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi all,
I've finally come around to writing a patch that stops dict lookup from
eating all exceptions that occur during lookup, like rare bugs in user
__eq__() methods. After another 2-hours long debugging session that
turned out to be caused
Michele Simionato [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Is there still time for new feature requests in Python 2.5?
I am missing a isgenerator function in the inspect module. Right now
I am using
def isgenerator(func):
return func.func_code.co_flags == 99
but it is
On 5/29/06, Tim Peters [EMAIL PROTECTED] wrote:
I think we should do as Thomas proposes: plan to make it an error in
2.6 (or 2.7 if there's a big outcry, which I don't expect) and accept
it with a warning in 2.5.
That's what I arrived at, although 2.4.3's checking behavior is
actually so
Perhaps more people could chime in? Am I being too anal about backward
compatibility here?
As a sometimes bug report reviewer, I would like the reported discrepancy
between the public docs and visible code behavior fixed one way or the
other (by changing the docs or code) since that is my
On 5/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
There's still a ton used under Modules. Also, if no flag is
specified, it will default to 0 (ie, METH_OLDARGS). I wonder how many
third party modules use METH_OLDARGS directly or more likely
indirectly.
These
Hi Guido,
On Mon, May 29, 2006 at 12:34:30PM -0700, Guido van Rossum wrote:
+1, as long as (as you seem to imply) PyDict_GetItem() still swallows
all exceptions.
Yes.
Fixing PyDict_GetItem() is a py3k issue, I think. Until then, there
are way too many uses. I wouldn't be surprised if after
Hi Raymond,
On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote:
I've finally come around to writing a patch that stops dict lookup from
eating all exceptions that occur during lookup, like rare bugs in user
__eq__() methods.
Is there a performance impact?
I believe that
[python-checkins]
* Added socket.recv_buf() and socket.recvfrom_buf() methods, that
use the buffer
protocol (send and sendto already did).
* Added struct.pack_to(), that is the corresponding buffer
compatible method to
unpack_from().
[Guido]
Hm... The file object has a similar
Terry Reedy wrote:
def isgenerator(func):
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
To me, part of the beauty of Python is that is so easy to write such things
so compactly, so that we do not need megaAPIs with hundreds of functions
and methods.
I think it's a very minor feature at best -- but I do admit to having
implemented this at least once so I'm not against adding it as a new
feature to the tempfile module. It's getting awfully late for 2.5
though... (feature freeze is at 2.5b1 which is planned for June 14
IIRC).
--Guido
On
Neal Norwitz wrote:
Also, it would be easy to detect METH_OLDARGS in PyCFunction_New and raise
an appropriate exception.
I agree with Martin this should raise a deprecation warning in 2.5.
why?
this is a clear case of unnecessary meddling. removing it won't remove
much code (a whopping
Fredrik Lundh wrote:
Terry Reedy wrote:
def isgenerator(func):
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
To me, part of the beauty of Python is that is so easy to write such things
so compactly, so that we do not need megaAPIs with hundreds of
Armin Rigo wrote:
As it turns out, I measured only 0.5% performance loss in Pystone.
umm. does Pystone even call lookdict?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On May 29, 2006, at 12:44 PM, Guido van Rossum wrote:
On 5/29/06, Tim Peters [EMAIL PROTECTED] wrote:
I think we should do as Thomas proposes: plan to make it an error in
2.6 (or 2.7 if there's a big outcry, which I don't expect) and
accept
it with a warning in 2.5.
That's what I
[Guido]
I think we should do as Thomas proposes: plan to make it an error in
2.6 (or 2.7 if there's a big outcry, which I don't expect) and accept
it with a warning in 2.5.
[Tim]
That's what I arrived at, although 2.4.3's checking behavior is
actually so inconsistent that it needs some
Terry Reedy wrote:
.. _contributor agreement:
http://www.python.org/psf/contrib-form-python.html
By itself, this link is inadequate since there is a blank for 'Initial
License' with no choices indicated. So the summary needs a link to an
instruction page also. The form is also a bit
On 5/29/06, Tim Peters [EMAIL PROTECTED] wrote:
[Tim] To be clear, Thomas proposed accepting it (whatever that means) until 3.0.[Guido] Fine with me.So who has a definition for what it means?
I know which 'it' I meant: the same 'it' as struct already accepts in Python 2.4 and before. Yes, it's
On 5/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
this is a clear case of unnecessary meddling.removing it won't removemuch code (a whopping 11 lines is dedicated to this), nor give any speedups whatsoever; all you're doing is generating extra work and support
issues for a bunch of third-party
Thomas Wouters wrote:
I know which 'it' I meant: the same 'it' as struct already accepts in
Python 2.4 and before. Yes, it's inconsistent between formatcodes and
valuetypes -- fixing that the whole point of the change -- but that's
how you define 'compatibility'; struct, by default, should
Thomas Wouters wrote:
On 5/29/06, *Fredrik Lundh* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
this is a clear case of unnecessary meddling. removing it won't remove
much code (a whopping 11 lines is dedicated to this), nor give any speed
ups whatsoever; all you're
On 5/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote: I know which 'it' I meant: the same 'it' as struct already accepts in Python 2.4 and before. Yes, it's inconsistent between formatcodes and valuetypes -- fixing that the whole point of the change -- but that's
how you define
On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote:
I've finally come around to writing a patch that stops dict lookup from
eating all exceptions that occur during lookup, like rare bugs in user
__eq__() methods.
Is there a performance impact?
I believe that this patch is
Georg Brandl wrote:
Isn't there at least a GCC __attribute__((deprecated))?
Yes, but it applies to functions only. I guess you could make
a __deprecated__ function, and then expand METH_OLDARGS to a
call of that function. That won't help in cases where there are
no flags given at all in the
Neal Norwitz wrote:
minus comments, etc yields several questions about whether some
values should use Py_ssize_t rather than C longs. In particular:
* hash values
Include/abstract.h: long PyObject_Hash(PyObject *o); // also in
object.h
Include/object.h:typedef long
Martin v. Löwis wrote:
Georg Brandl wrote:
Isn't there at least a GCC __attribute__((deprecated))?
Yes, but it applies to functions only. I guess you could make
a __deprecated__ function, and then expand METH_OLDARGS to a
call of that function. That won't help in cases where there are
no
Hi Raymond,
On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote:
Please run some better benchmarks and do more extensive assessments on the
performance impact.
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
the tests I try to time, and even going into
On 5/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote: minus comments, etcyields several questions about whether some values should use Py_ssize_t rather than C longs.In particular: * ints:Include/intobject.h:long ob_ival;
As Tim says, this is way out of scope for 2.5. Guido said
Neal Norwitz wrote:
Should the following values be ints (limited to 2G)?
* dict counts (ma_fill, ma_used, ma_mask)
I think Tim said he'll look into them.
* line #s and column #s
I think we should really formalize a limit, and then enforce it
throughout. column numbers shouldn't exceed
On 5/29/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
.. _contributor agreement:
http://www.python.org/psf/contrib-form-python.html
By itself, this link is inadequate since there is a blank for 'Initial
License' with no choices indicated. So the summary needs a link to
Thomas Wouters wrote:
Neal Norwitz wrote:
minus comments, etc yields several questions about whether some
values should use Py_ssize_t rather than C longs. In particular:
* ints: Include/intobject.h:long ob_ival;
As Tim says, this is way out of scope for 2.5.
Georg Brandl wrote:
I thought more about PyArg_Parse for __deprecated__.
Ah, PyArg_Parse can, of course. Having it actually do that should not
hurt, either - but you need a reliable check whether the compiler
supports __deprecated__.
Regards,
Martin
Guido van Rossum wrote:
I think that should be done for 2.5, but nothing else. Or, perhaps
a deprecation warning could be generated if it is still used.
I'll let Martin decide this one.
I just sent a message to some that producing a DeprecationWarning is
fine, but now I read some opposition;
On 5/29/06, Martin v. Löwis
[EMAIL PROTECTED] wrote:
I agree using Py_ssize_t would be a smaller change, and one thatlikely has less performance impact. It would still be a large change,and should be only done if we know for sure we don't want it to be
a 64-bit type always the next day.Well,
Armin Rigo wrote:
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
the tests I try to time, and even going into an infinite loop consuming
all my memory - since the NFS sprint. Am I allowed to be grumpy here,
and repeat that speed should not be used to justify bugs?
Re-hi,
On Mon, May 29, 2006 at 11:34:28PM +0200, Armin Rigo wrote:
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
the tests I try to time, and even going into an infinite loop consuming
all my memory
Ah, it's a corner case of str.find() whose behavior just changed.
Thomas Wouters wrote:
But switching PyInts to use (a symbolic type of the same size as)
Py_ssize_t means that, when the time comes that 32-bit architectures are
rare, Win64 isn't left as the only platform (barring other LLP64
systems) that has slow 33-to-64-bit Python numbers (because they'd
Martin v. Löwis wrote:
Guido van Rossum wrote:
I think that should be done for 2.5, but nothing else. Or, perhaps
a deprecation warning could be generated if it is still used.
I'll let Martin decide this one.
I just sent a message to some that producing a DeprecationWarning is
fine, but
Armin Rigo wrote:
Ah, it's a corner case of str.find() whose behavior just changed.
Previously, 'abc'.find('', 100) would return -1, and now it returns 100.
Just to confuse matters, the same test with unicode returns 100, and has
always done so in the past. (Oh well, one of these again...)
Hi Fredrik,
On Tue, May 30, 2006 at 12:01:46AM +0200, Fredrik Lundh wrote:
not unless you can produce some code. unfounded accusations don't
belong on this list (it's not like the sprinters didn't test the code on
a whole bunch of platforms), and neither does lousy benchmarks (why are
you
Armin Rigo wrote:
Hi Raymond,
On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote:
Please run some better benchmarks and do more extensive assessments on the
performance impact.
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
the
Hi Fredrik,
On Tue, May 30, 2006 at 12:23:04AM +0200, Fredrik Lundh wrote:
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last
On May 29, 2006, at 1:18 PM, Bob Ippolito wrote:
On May 29, 2006, at 12:44 PM, Guido van Rossum wrote:
On 5/29/06, Tim Peters [EMAIL PROTECTED] wrote:
I think we should do as Thomas proposes: plan to make it an
error in
2.6 (or 2.7 if there's a big outcry, which I don't expect) and
Thomas Wouters wrote:
If 2.5 warns and does the old thing, the upgrade path is easy and
defendable. This is also why there are future statements -- I
distinctly recall making the same argument back then :-) The cost of
continuing the misfeatures in struct for one release does not weigh
up to
Raymond Hettinger wrote:
If it is really 0.5%, then we're fine. Just remember that PyStone is an
amazingly uninformative and crappy benchmark.
Since Armin seems to not like having to justify his patch with any
performance testing, I wrote a handful of dict insertion exercises and
could find
Fredrik Lundh wrote:
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last week), count, etc.
Although Tim pointed out that
[Bob Ippolito]
...
Actually, should this be a FutureWarning or a DeprecationWarning?
Since it was never documented, UndocumentedBugGoingAwayError ;-)
Short of that, yes, DeprecationWarning. FutureWarning is for changes
in non-exceptional behavior (.e.g, if we swapped the meanings of
and in
On 5/29/06, Greg Ewing [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last week),
[Adding the py3k list; please remove python-dev in followups.]
On 5/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I thought Py3k will have a single integer type whose representation
varies depending on the value being represented.
That's one proposal. Another is to have an abstract 'int'
On 5/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
I thought more about PyArg_Parse for __deprecated__.
Ah, PyArg_Parse can, of course. Having it actually do that should not
hurt, either - but you need a reliable check whether the compiler
supports __deprecated__.
[Greg Ewing]
Although Tim pointed out that replace() only regards
n+1 empty strings as existing in a string of lenth
n. So for consistency, find() should only find them
in those places, too.
[Guido]
And abc.count() should return 4.
And it does, but too much context was missing in Greg's
On 5/29/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 5/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
this is a clear case of unnecessary meddling. removing it won't remove
much code (a whopping 11 lines is dedicated to this), nor give any speed
ups whatsoever; all you're doing is
[Armin Rigo]
...
...
Am I allowed to be grumpy here, and repeat that speed should not be
used to justify bugs?
As a matter of fact, you are. OTOH, nobody at the sprint made that
argument, so nobody actually feels shame on that count :-)
I apologize for the insufficiently reviewed
On 5/29/06, Georg Brandl [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
is there some natural and obvious connection between generators and that
number that I'm missing, or is that constant perhaps best hidden inside
some introspection support module?
It seems to be a combination of
Guido van Rossum wrote:
struct PyInt{
struct PyObject ob;
Py_ssize_t value_or_size;
char is_long;
digit ob_digit[1];
};
Nice. I guess if we store the long value in big-endian order we could
drop is_long, since the first digit of the long would always be
nonzero. This would save
Guido van Rossum wrote:
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last week), count, etc.
Although Tim pointed out that
Armin Rigo wrote:
I know this. These corner cases are debatable and different answers
could be seen as correct, as I think is the case for find(). My point
was different: I was worrying that the recent change in str.find() would
needlessly send existing and working programs into infinite
77 matches
Mail list logo
