[Python-Dev] fixing buildbots

I've been starting to get some of the buildbots working again. There was some massive problem on May 25 where a ton of extra files were left around. I can't remember if I saw something about that at the NFS sprint or not. There is a lingering problem that I can't fix on all the boxes. Namely:

Re: [Python-Dev] Remove METH_OLDARGS?

On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > OTOH, perhaps a deprecation warning on PyArgs_Parse() is sufficient? > > What about that? It doesn't address other cases where OLDARGS are > > used without PyArgs_Parse though. > > What other cases remain? People might have complex arg

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 p

Re: [Python-Dev] Remove METH_OLDARGS?

Neal Norwitz wrote: > How can users find the implicit use of METH_OLDARGS in code like this: > > static struct PyMethodDef gestalt_methods[] = { >{"gestalt", gestalt_gestalt}, >{NULL, NULL} /* Sentinel */ > }; > > static PyMethodDef SwiMethods[]= { > { "swi", swi_swi,0}, > {

Re: [Python-Dev] Integer representation (Was: ssize_t question: longs in header files)

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

Re: [Python-Dev] feature request: inspect.isgenerator

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 combina

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

[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 excepti

[Python-Dev] Weekly Python Patch/Bug Summary

Patch / Bug Summary ___ Patches : 375 open ( -3) / 3264 closed (+26) / 3639 total (+23) Bugs: 910 open ( +3) / 5851 closed (+20) / 6761 total (+23) RFE : 217 open ( -1) / 220 closed ( +3) / 437 total ( +2) New / Reopened Patches __ Minor Cor

Re: [Python-Dev] Remove METH_OLDARGS?

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 do

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

[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 i

Re: [Python-Dev] Remove METH_OLDARGS?

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 __deprecat

Re: [Python-Dev] Integer representation (Was: ssize_t question: longs in header files)

[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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 > > l

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 th

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 4:35 PM, Delaney, Timothy (Tim) wrote: > 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 >> con

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 fin

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 > u

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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'

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 >

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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...

Re: [Python-Dev] Remove METH_OLDARGS?

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

Re: [Python-Dev] Integer representation (Was: ssize_t question: longs in header files)

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'

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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.

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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: [Python-Dev] ssize_t question: longs in header files

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

Re: [Python-Dev] Contributor agreements (was Re: DRAFT: python-dev summary for 2006-04-01 to 2006-04-15)

Steven Bethard wrote: >> There's another page somewhere in the PSF section that talks about >> contributor >> agreements in general - maybe that would be a better link for the summary? > > Sounds like it. (That wasn't anywhere in the thread.) Does > http://www.python.org/psf/contrib/ seem like

Re: [Python-Dev] Remove METH_OLDARGS?

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 opposi

Re: [Python-Dev] Remove METH_OLDARGS?

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 _

Re: [Python-Dev] ssize_t question: longs in header files

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

Re: [Python-Dev] Contributor agreements (was Re: DRAFT: python-dev summary for 2006-04-01 to 2006-04-15)

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 nee

Re: [Python-Dev] ssize_t: ints in header files

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

Re: [Python-Dev] ssize_t question: longs in header files

On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> 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

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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

Re: [Python-Dev] Remove METH_OLDARGS?

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

Re: [Python-Dev] ssize_t question: longs in header files

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 (*hashfunc)

Re: [Python-Dev] Remove METH_OLDARGS?

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 meth

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

> 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 tha

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 d

Re: [Python-Dev] Remove METH_OLDARGS?

Thomas Wouters 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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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, sho

Re: [Python-Dev] Remove METH_OLDARGS?

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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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,

Re: [Python-Dev] Contributor agreements (was Re: DRAFT: python-dev summary for 2006-04-01 to 2006-04-15)

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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[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" ne

[Python-Dev] Contributor agreements (was Re: DRAFT: python-dev summary for 2006-04-01 to 2006-04-15)

-- Contributor agreements -- If you're listed in the `Python acknowledgments`_, and you haven't signed a `contributor agreement`_, please submit one as soon as possible. Note that this includes even the folks that have been around forever -- the PSF would l

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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. >> >> Th

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

Armin Rigo wrote: > As it turns out, I measured only 0.5% performance loss in Pystone. umm. does Pystone even call lookdict? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://ma

Re: [Python-Dev] feature request: inspect.isgenerator

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 w

Re: [Python-Dev] Remove METH_OLDARGS?

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 whopp

Re: [Python-Dev] PEP 42 - New kind of Temporary file

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 5/28/06

Re: [Python-Dev] feature request: inspect.isgenerator

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

Re: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c

[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 fil

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 believ

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 aft

Re: [Python-Dev] Remove METH_OLDARGS?

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 > >> indirec

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

>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 w

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 > ac

Re: [Python-Dev] feature request: inspect.isgenerator

"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 >

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[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,

Re: [Python-Dev] Let's stop eating exceptions in dict lookup

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 ___

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 r

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

"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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

[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

Re: [Python-Dev] ssize_t question: longs in header files

[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

Re: [Python-Dev] ssize_t question: longs in header files

[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 expec

[Python-Dev] Let's stop eating exceptions in dict lookup

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. http://python.o

Re: [Python-Dev] epoll implementation

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

[Python-Dev] DRAFT: python-dev summary for 2006-04-01 to 2006-04-15

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 =

Re: [Python-Dev] Syntax errors on continuation lines

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 re

Re: [Python-Dev] Syntax errors on continuation lines

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 li

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 fi

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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 . If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is th

Re: [Python-Dev] ssize_t question: longs in header files

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.

Re: [Python-Dev] Remove METH_OLDARGS?

Neal Norwitz wrote: >> These modules can be converted. > > We can convert the one's in Python, but not the third party ones. > It's also very difficult to search for something that's not there. > You need to review every PyMethodDef entry to verify it has a METH_* > flag. These implicit METH_OLD

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Well, the behavior change is in response to a bug . 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 ho

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

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

Re: [Python-Dev] ssize_t: ints in header files

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 _

[Python-Dev] feature request: inspect.isgenerator

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 ___