[issue6673] Py3.1 hangs in coroutine and eats up all memory

Stefan Behnel added the comment: Very good argumentation, thanks Nick! I think this is worth being fixed in the 3.1 series. -- ___ Python tracker ___ ___

[issue6673] Py3.1 hangs in coroutine and eats up all memory

Changes by Stefan Behnel : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1424148] urllib.FancyURLopener.redirect_internal looses data on POST!

Senthil added the comment: I am assigning this to myself. I shall do some research on this issue + plus current standings by other clients/libraries and come out with a summary. -- assignee: -> orsenthil ___ Python tracker

[issue6714] memmove fails with unicode strings

Changes by Eric Smith : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue6714] memmove fails with unicode strings

Giorgos Verigakis added the comment: Yes, you are right. I thought that the different behavior was weird. Sorry this is not a bug. -- status: open -> closed ___ Python tracker _

[issue6712] sys._getframe is not available on all Python implementations

Brett Cannon added the comment: On Sun, Aug 16, 2009 at 16:23, Michael Foord wrote: > > Michael Foord added the comment: > > I meant in IronPython of course. D'oh. Anyway, I made the change to > inspect to keep it compatible with IronPython so I can make the > documentation change. > > A mentio

[issue6712] sys._getframe is not available on all Python implementations

Michael Foord added the comment: I meant in IronPython of course. D'oh. Anyway, I made the change to inspect to keep it compatible with IronPython so I can make the documentation change. A mention in the sys._getframe docs that it is not guaranteed to exist across implementations would be usefu

[issue6712] sys._getframe is not available on all Python implementations

Brett Cannon added the comment: It sounds like inspect needs to have its docs updated such that it makes it explicit inspect.currentframe() requires sys._getframe() to exist to return anything of use (the code returns None in other cases). So the public API can exist, but it needs to say what

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

Gregory P. Smith added the comment: btw, when using async io (poll, select, etc) I -think- your socket will see a read event when the server closes the connection (sends you a FIN or even a RST) at which point your sock.recv() when you've been told data was ready will return 0 bytes indicating t

[issue6712] sys._getframe is not available on all Python implementations

Michael Foord added the comment: It's actually quite annoying that inspect takes a private API (that has warnings in the documentation about its use) and makes it public. It's just a direct alias. That in itself is not a good reason to say the _getframe should be public. Python frames are not a

[issue6712] sys._getframe is not available on all Python implementations

Gregory P. Smith added the comment: Yeah I'd take this to the list. Perhaps this is destined to be a public API. -- nosy: +gregory.p.smith ___ Python tracker ___ ___

[issue6712] sys._getframe is not available on all Python implementations

Tobias Ivarsson added the comment: While it is true that not all Python implementations support sys._getframe() in some or all execution modes, Jython does support it, even IronPython supports it with the proper startup parameters these days. More importantly sys._getframe() [or something equiv

[issue6281] Bug in hashlib

Gregory P. Smith added the comment: That code was indeed a mess. I've incorporated most suggestions from your cleaned up version (and fixed a bug in it) in trunk r74479. Have you ever seen __get_builtin_constructor fail in practice? I can imagine that packing up a stripped down python interpr

[issue6714] memmove fails with unicode strings

Eric Smith added the comment: What platform is this on? For a ucs4 platform, that is what I'd expect the result to be. Check sys.maxunicode to see if you have a ucs2 or ucs4 build. What do you expect as the result? Remember that memmove takes a count of bytes, not a character count. -

[issue6714] memmove fails with unicode strings

New submission from Giorgos Verigakis : A demonstration: >>> buf = create_string_buffer('__') >>> memmove(buf, 'SPAM', 4) 614584 >>> buf.raw 'SPAM__\x00' >>> buf = create_string_buffer('__') >>> memmove(buf, u'SPAM', 4) 614672 >>> buf.raw 'S\x00\x00\x00__\x00' FWIW memmove fails in Pyt

[issue6665] fnmatch fails on filenames containing \n character

Gregory P. Smith added the comment: I'll backport this to 2.6 and 3.1 later (its too late for 3.1.1). -- versions: -Python 2.7, Python 3.2 ___ Python tracker ___ ___

[issue6665] fnmatch fails on filenames containing \n character

Gregory P. Smith added the comment: fixed in trunk r74475, py3k r74476 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue6712] sys._getframe is not available on all Python implementations

Brett Cannon added the comment: The leading underscore is meant to convey that it is not guaranteed to exist. But in spite of this, we do plan long-term to make it explicit what all interpreters are expected to (not) support. -- nosy: +brett.cannon ___

[issue6665] fnmatch fails on filenames containing \n character

Gregory P. Smith added the comment: changing the '$' to \Z(?ms)' fixes the problem. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue6665] fnmatch fails on filenames containing \n character

Gregory P. Smith added the comment: aww, i guess the _cache does cache the result of the glob -> regular expression translation. it needs to stay for that. -- ___ Python tracker ___

[issue6665] fnmatch fails on filenames containing \n character

Gregory P. Smith added the comment: haha wow I just read the fnmatch code... trunk r2734 | guido | 1992-01-12 added fnmatch._cache for it to cache compiled regular expressions. That has -long- since become unnecessary as the re module does that itself. ;) I'll clean this up while fixing this

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Gregory P. Smith added the comment: +1 on the PyXXX_ClearFreeList patch and calling them from gc.collect() as is done with the others. I agree with Guido, don't add a tp_free_list slot as the common case would be NULL. Regarding gc clearing freelists: I agree with Antoine and Martin. Clearing

[issue6665] fnmatch fails on filenames containing \n character

Changes by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list maili

[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions

New submission from Gawain Bolton : Converting integer & long types to their ASCII representation is a task which can be quite CPU intensive due to the division & modulo operations. For long integers having hundreds or thousands of digits, this can take a truly significant amount of CPU time. I

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Martin v. Löwis added the comment: I still stand by my suggestion to free memory as a side effect of garbage collection. It may well be that an application will start re-allocating blocks that soon end up in the free list again. OTOH, it may also be that releasing those free lists, along with th

[issue6627] threading.local() does not work with C-created threads

Changes by Giorgos Verigakis : -- nosy: +verigak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Changes by Raymond Hettinger : -- resolution: accepted -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue6695] PyXXX_ClearFreeList for dict, set, and list

R. David Murray added the comment: FWIW, I agree with Antoine here. I think user expectation is that when "garbage" is collected, at least some freed memory will be returned to the operating system. The normal user's conception of what "garbage" is has nothing to do with cycles. It just so ha

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Antoine Pitrou added the comment: The change was originally made in r60797, « Implemented Martin's suggestion to clear the free lists during the garbage collection of the highest generation ». -- nosy: +christian.heimes, loewis ___ Python tracker

[issue6244] Support for tcl 8.6

Guilherme Polo added the comment: This has been committed now, r74471,74472 (trunk) and r74473 (py3k). -- resolution: -> accepted status: open -> closed ___ Python tracker ___ _

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Antoine Pitrou added the comment: > When did that happen? I agree with Raymond. The cyclic gc should just > reclaim cycles. People don't care about referential cycles, they care about freeing some memory (if memory was available in infinite quantities nobody would care about breaking cycles).

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Skip Montanaro added the comment: >> I thought GC was expected to eliminate reference cycles. Antoine> Of course, but it's also the de facto API when wanting to Antoine> reclaim memory. When did that happen? I agree with Raymond. The cyclic gc should just reclaim cycles. Skip -

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue6712] sys._getframe is not available on all Python implementations

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue6712] sys._getframe is not available on all Python implementations

New submission from Johannes Janssen : As I learned on the mailing list the function sys._getframe() is not available on all Python implementations (e.g. jython). This information should be added to the documentation. -- assignee: georg.brandl components: Documentation messages: 91629 no