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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
___
[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
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
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,
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
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
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
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
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
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
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
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
[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
[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.
29 matches
Mail list logo