Re: [Python-Dev] [Python-checkins] r45334 - python/trunk/Lib/test/leakers/test_gen1.py python/trunk/Lib/test/leakers/test_generator_cycle.py python/trunk/Lib/test/leakers/test_tee.py

2006-04-14 Thread Neal Norwitz
On 4/13/06, Tim Peters [EMAIL PROTECTED] wrote: Rather than delete a leak test, perhaps we could simply move it into a new old-leaking-tests subdirectory? Likewise for crash tests. When the bug reappears, it's helfpul to have the focussed (whittled-down) old test that provoked it handy.

[Python-Dev] Calling Thomas Heller and Richard Jones

2006-04-14 Thread Steve Holden
If Thomas Heller and Richard Jones haven't recently received email from me (and are reading this list, naturally) I'd appreciate it if they'd get in touch with me in the next day or so. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd

Re: [Python-Dev] PEP 302 support for pydoc, runpy, etc.

2006-04-14 Thread Nick Coghlan
Phillip J. Eby wrote: Anybody have any thoughts, comments, or questions? This all sounds good to me. Will it also eliminate the current quirk in the runpy emulation where it searches the metapath in a slightly different order than the actual import machinery does? (From what you wrote, I

Re: [Python-Dev] int vs ssize_t in unicode

2006-04-14 Thread Neal Norwitz
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Neal Norwitz wrote: I just grepped for INT_MAX and there's a ton of them still (well 83 in */*.c). Some aren't an issue like posixmodule.c, those are _SC_INT_MAX. marshal is probably ok, but all uses should be verified. Really all

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

2006-04-14 Thread Guido van Rossum
On 4/14/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 14 April 2006 02:31, Martin v. Löwis wrote: Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I

Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter

2006-04-14 Thread Martin v. Löwis
Neal Norwitz wrote: I'll leave this decision to Martin or someone else, since I'm not familiar with the ramifications. Since it was documented as unsigned, I think it's reasonable to consider changing. Though it could create signed-ness warnings in other modules. I'm not sure but it's

Re: [Python-Dev] Procedure for sandbox branches in SVN?

2006-04-14 Thread Martin v. Löwis
Tim Peters wrote: Just do it. Branches under SVN are cheap, go fast, and are pretty easy to work with. Even better, because a branch is just another named directory in SVN's virtual file system, you can svn remove it when you're done with it (just like any other directory). That's all true.

Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter

2006-04-14 Thread M.-A. Lemburg
Martin v. Löwis wrote: Neal Norwitz wrote: I'll leave this decision to Martin or someone else, since I'm not familiar with the ramifications. Since it was documented as unsigned, I think it's reasonable to consider changing. Though it could create signed-ness warnings in other modules. I'm

Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter

2006-04-14 Thread Martin v. Löwis
M.-A. Lemburg wrote: I'd argue that such code is broken anyway: 3rd party code simply cannot make any assumptions on the typedef behind Py_UNICODE. The code would work just fine now, but will stop working with the change. Users of the code might not be open to arguments. In any case, it's up

Re: [Python-Dev] Procedure for sandbox branches in SVN?

2006-04-14 Thread Fredrik Lundh
Tim Peters wrote: Just do it. Branches under SVN are cheap, go fast, and are pretty easy to work with. Even better, because a branch is just another named directory in SVN's virtual file system, you can svn remove it when you're done with it (just like any other directory). footnote: if

Re: [Python-Dev] New-style icons, .desktop file

2006-04-14 Thread Andrew Clover
Morning! I've done some tweaks to the previously-posted-about icon set, taking note of some of the comments here and on -list. In particular, amongst more minor changes: - added egg icon (based on zip) - flipped pycon to work better with shortcut arrow - emphasised borders of 32x32

Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter

2006-04-14 Thread M.-A. Lemburg
Martin v. Löwis wrote: M.-A. Lemburg wrote: I'd argue that such code is broken anyway: 3rd party code simply cannot make any assumptions on the typedef behind Py_UNICODE. The code would work just fine now, but will stop working with the change. Users of the code might not be open to

Re: [Python-Dev] New-style icons, .desktop file

2006-04-14 Thread Nick Coghlan
Andrew Clover wrote: Morning! I've done some tweaks to the previously-posted-about icon set, taking note of some of the comments here and on -list. And I still think they're pretty :) - emphasised borders of 32x32 version of pycon, and changed text colour, in order to distinguish

[Python-Dev] IMPORTANT 2.5 API changes for C Extension Modules and Embedders

2006-04-14 Thread Neal Norwitz
If you don't write or otherwise maintain Python Extension Modules written in C (or C++) or embed Python in your application, you can stop reading. Python 2.5 alpha 1 was released April 5, 2006. The second alpha should be released in a few weeks. There are several changes which can cause C

Re: [Python-Dev] PEP 359: The make Statement

2006-04-14 Thread skip
Travis I generally like the idea. A different name would be better. Travis Here's a list of approximate synonyms that might work (ordered Travis by my preference...) ... lots of suggestions elided ... None of the alternatives seem better to me than make or create. In fact,

Re: [Python-Dev] New-style icons, .desktop file

2006-04-14 Thread Fred L. Drake, Jr.
On Friday 14 April 2006 06:35, Andrew Clover wrote: Files and preview here: http://doxdesk.com/img/software/py/icons2.zip http://doxdesk.com/img/software/py/icons2.png Very nice! -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___

Re: [Python-Dev] Procedure for sandbox branches in SVN?

2006-04-14 Thread Tim Peters
[Martin v. Löwis] That's all true. Of course, removing the branch won't free up any disk space - it will just remove the branch from the view (IOW, it is also easy to bring it back if it was removed mistakenly). Right! I'm implicitly addressing a different issue, namely that two reasons for

[Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Tim Peters
When possible finalizers were added to generators, the implementation at first said that all generators need finalizing. As a result, some old tests in test_generators.py started leaking cyclic trash. As a result of that, someone(s) added a number of explicit close gimmicks to those tests, to

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

2006-04-14 Thread John J Lee
Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... On Fri, 14 Apr 2006, John J Lee wrote: [...] Assuming this is fixed in 2.5 final, is there some way to write doctests that work on both 2.4 and 2.5? If not,

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Phillip J. Eby
At 03:49 PM 4/14/2006 -0400, Tim Peters wrote: That eventually pointed to an off-by-one error in the new PyGen_NeedsFinalizing(), where reading up trash made it very likely that old generators containing an active loop would falsely claim they need finalization. Alas, fix that, and Python

Re: [Python-Dev] PEP 359: The make Statement

2006-04-14 Thread Ian Bicking
BJörn Lindqvist wrote: [nice way to declare properties with make] Of course, properties are only one of the many possible uses of the make statement. The make statement is useful in essentially any situation where a name is associated with a namespace. So, for So far, in this thread

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Thomas Wouters
On 4/14/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 03:49 PM 4/14/2006 -0400, Tim Peters wrote: That eventuallypointed to an off-by-one error in the new PyGen_NeedsFinalizing(),where reading up trash made it very likely that old generatorscontaining an active loop would falsely claim they need

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Phillip J. Eby
At 11:51 PM 4/14/2006 +0200, Thomas Wouters wrote: On 4/14/06, Phillip J. Eby mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: At 03:49 PM 4/14/2006 -0400, Tim Peters wrote: That eventually pointed to an off-by-one error in the new PyGen_NeedsFinalizing(), where reading up trash made it

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Thomas Wouters
On 4/15/06, Phillip J. Eby [EMAIL PROTECTED] wrote: Interestingly, this code does *not* crash the interpreter on its own, onlywhen run as a doctest (with or without regrtest).Actually, it does, you just have to force GC to clean up stuff (rather than wait for the interpreter-exit to just toss the

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Phillip J. Eby
At 06:26 PM 4/14/2006 -0400, Phillip J. Eby wrote: If you replace the fun_tests in test_generators with this, and remove all the other tests (e.g. pep_tests, tut_tests, etc.) you can still get it to crash. The code above is much shorter, but has the disadvantage that I don't really know what it's

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Thomas Wouters
On 4/15/06, Thomas Wouters [EMAIL PROTECTED] wrote: (I first thought the problem was caused by gen_dealloc doing 'Py_DECREF(gen-gen_frame)' instead of 'frame = gen-gen_frame; gen-gen_frame = NULL; Py_DECREF(frame)', but that isn't the case. It should do it that way, I believe, but it's not the

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Phillip J. Eby
At 01:11 AM 4/15/2006 +0200, Thomas Wouters wrote: On 4/15/06, Thomas Wouters mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: (I first thought the problem was caused by gen_dealloc doing 'Py_DECREF(gen-gen_frame)' instead of 'frame = gen-gen_frame; gen-gen_frame = NULL; Py_DECREF(frame)', but

Re: [Python-Dev] Debugging opportunity :-)

2006-04-14 Thread Tim Peters
[Phillip J. Eby] Even with the close() gimmicks still in place? If so, it sounds like the safest thing for a2 might be to claim that generators always need finalizing. :( LOL! Been there many times before: Python's gc really does work, but it's as unforgivingly delicate as any dance you're

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

2006-04-14 Thread Tim Peters
[John J Lee] Assuming this is fixed in 2.5 final, is there some way to write doctests that work on both 2.4 and 2.5? If not, should something like doctest.IGNORE_EXCEPTION_DETAIL be added -- say IGNORE_EXCEPTION_MODULE? [also John] Sorry, please ignore the post of mine I'm replying to here.