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

[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

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

[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: [Python-Dev] Debugging opportunity :-)

At 01:11 AM 4/15/2006 +0200, Thomas Wouters wrote: >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

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

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 :-)

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 i

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

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 :-)

At 11:51 PM 4/14/2006 +0200, Thomas Wouters wrote: >On 4/14/06, Phillip J. Eby ><[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

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

On 4/14/06, Phillip J. Eby <[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 very likely that old generators>containing an active loop would falsely claim the

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

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 t

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

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 s

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

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

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

On Thu, 13 Apr 2006, "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 also think the traceback module should be corrected, and the test cases u

[Python-Dev] Debugging opportunity :-)

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] PEP 359: The "make" Statement

[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 that is the only useful us

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

[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

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

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. ___ Python-Dev maili

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

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 fa

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

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 extens

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

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 distin

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

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

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 ver

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

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:

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

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] unicode vs buffer (array) design issue can crash interpreter

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 modul

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

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

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

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 po

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

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 a

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

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

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

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 belie