[issue1944] Documentation for PyUnicode_AsString (et al.) missing.

New submission from Alexandre Vassalotti: I was wandering whether the pointer returned by PyUnicode_AsString needs to be freed after usage (It turned it doesn't since the result is cached). However, I found out that there isn't any documentation on docs.python.org about the PyUnicode_AsString and

[issue1926] NNTPS support in nntplib

Bill Janssen added the comment: Great, Ray. I don't see any test cases for the nntp library in the Lib/test/ directory. How can we make sure it works on the buildbots? Bill On Jan 25, 2008 12:49 PM, Ray Chason <[EMAIL PROTECTED]> wrote: > > Ray Chason added the comment: > > Here's take 2. > >

[issue1943] improved allocation of PyUnicode objects

Antoine Pitrou added the comment: I just tried bumping KEEPALIVE_SIZE_LIMIT to 200. It makes up for a bit of the speedup, but the PyVarObject version is still faster. Moreover, and perhaps more importantly, it eats less memory (800KB less in pybench, 3MB less when running the whole test suite).

[issue1943] improved allocation of PyUnicode objects

Marc-Andre Lemburg added the comment: The Unicode object was designed not to be a PyVarObject (in contrast to the string object), so I'm not sure what you would want to break that design in return for a mere 10% speedup. Note that turning the objects into PyVarObjects removes the ability to exte

[issue1941] 2.6 stdlib using with statement

Raymond Hettinger added the comment: It means to that the test suites are likely inadequate in this department and that you need to carefully check each transformation to make sure it doesn't do something subtlely different. __ Tracker <[EMAIL PROTECTED]>

[issue1943] improved allocation of PyUnicode objects

Changes by Georgij Kondratjev: -- nosy: +orivej __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1935] test_descr.py converted to unittest

Brett Cannon added the comment: Just so you know, Amaury, a student did a conversion for GHOP: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=291 . It was not checked in yet as we are waiting for contributor forms first. But perhaps you can have a look at it and s

[issue1943] improved allocation of PyUnicode objects

Changes by Antoine Pitrou: Added file: http://bugs.python.org/file9297/stringbench3k.py __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing l

[issue1943] improved allocation of PyUnicode objects

New submission from Antoine Pitrou: This is an attempt at improving allocation of str (PyUnicode) objects. For that it does two things: 1. make str objects PyVarObjects, so that the object is allocated in one pass rather than two 2. maintain an array of freelists, each for a given str length, so

[issue1941] 2.6 stdlib using with statement

Christian Heimes added the comment: Benjamin Peterson wrote: > Sorry, but what does that mean? All tests are passing with the changes. Tests aren't a proof for correctness. A failing test proofs either an error in the implementation or in the test suite. The reverse "all tests are passing => eve

[issue1942] test_plistlib started failing

Guido van Rossum added the comment: Fixed by Crys in r60333. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1941] 2.6 stdlib using with statement

Benjamin Peterson added the comment: Sorry, but what does that mean? All tests are passing with the changes. __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue1942] test_plistlib started failing

New submission from Guido van Rossum: Probably a merge glitch. -- components: Macintosh messages: 61724 nosy: gvanrossum priority: urgent severity: normal status: open title: test_plistlib started failing type: behavior versions: Python 3.0 __ Tracker <[E

[issue1941] 2.6 stdlib using with statement

Raymond Hettinger added the comment: Please make darned sure these changes are semantically neutral. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-li

[issue1941] 2.6 stdlib using with statement

Jean-Paul Calderone added the comment: There may not be a guarantee, but it will with the current implementation, and the discussion on this ticket seems to be very geared towards CPython implementation peculiarities. __ Tracker <[EMAIL PROTECTED]>

[issue1941] 2.6 stdlib using with statement

Adam Olsen added the comment: Yes, but there's no guarantee it will even reach the C function. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mai

[issue1631394] sre module has misleading docs

Tom Lynn added the comment: Nice changes to the wording. (For the record: it's r60316 in fact.) _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bug

[issue1941] 2.6 stdlib using with statement

Benjamin Peterson added the comment: This new patch removes the modulefinder changes. I was the one you submitted #1910 which probably sparked the performance debate. In this patch, I tried to avoid these touchy places. Added file: http://bugs.python.org/file9295/stdlib-with-stmt2.diff ___

[issue1941] 2.6 stdlib using with statement

Jean-Paul Calderone added the comment: It's explicitly not (and Guido said this is what he wanted, several times). However, CPython will not raise a KeyboardInterrupt in the middle of a C function. Hence my parenthetical about implementing the lock type in C. __

[issue1941] 2.6 stdlib using with statement

Adam Olsen added the comment: Is there a guarantee that the with-statement is safe in the face of KeyboardInterrupt? PEP 343 seems to imply it's not, using it as a reason for why we need no special handling if __exit__ fails. -- nosy: +Rhamphoryncus __ T

[issue1941] 2.6 stdlib using with statement

Jean-Paul Calderone added the comment: The patch doesn't change the threading module, so I'm not sure if there's anything in particular you think is performance critical there. The places where it uses try/finally are: * _Condition.wait. This performs operations on a mutex which are much slo

[issue1941] 2.6 stdlib using with statement

Christian Heimes added the comment: A while ago Raymond explained on Python developer list that the with statement is slightly slower than a try/finally block. Performance critical sections like the threading module must not use the with statement. -- assignee: -> rhettinger keywords: +

[issue1941] 2.6 stdlib using with statement

Thomas Heller added the comment: modulefinder should be kept compatible with Python 2.2, so please do not apply the patch for this module. See also PEP 291. No idea about the other modules. -- nosy: +theller __ Tracker <[EMAIL PROTECTED]>

[issue1941] 2.6 stdlib using with statement

New submission from Benjamin Peterson: This patch modernizes many modules in the stdlib by making them using the with statement. They affected modules are modulefinder, ftplib, cookielib, shutil, pydoc, platform, _LWPCookieJar, mailbox, _MozillaCookieJar, and zipfile. -- components: Libr

[issue1938] test_zipfile failure

Giampaolo Rodola' added the comment: You're right, sorry. I'll do that. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1938] test_zipfile failure

Christian Heimes added the comment: Applied in r60326 Thanks! Next time please explain the ratio for the fix in a sentence and don't commit a patch with absolute file names. -- nosy: +tiran priority: -> low resolution: -> fixed status: open -> closed _

[issue1473257] Add a gi_code attr to generators

Georg Brandl added the comment: Reformatted the patch to use tabs and committed as r60324. -- assignee: gvanrossum -> georg.brandl resolution: -> accepted status: open -> closed _ Tracker <[EMAIL PROTECTED]>

[issue1940] curses.filter can not be used as described in its documentation

Georg Brandl added the comment: You're right. I fixed this in r60322, r60323 (2.5). -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1872] change the bool struct format code from 't' to '?'

Changes by Georgij Kondratjev: -- nosy: +orivej __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1940] curses.filter can not be used as described in its documentation

New submission from Robin Bryce: curses.filter forces the top most window to 1 line tall and preserves existing tty content. It must be called *before* curses.initscr in order to acheive this. The python documentation states that curses.filter must be called before initscr but the implementation

[issue1342] Crash on Windows if Python runs from a directory with umlauts

Changes by Giovanni Bajo: -- nosy: +rasky __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1928] test_urllib fails

Georg Brandl added the comment: Fixed in r60318 -- one of the changes to urllib didn't survive the merge to py3k. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> ___

[issue1934] os.path.isabs documentation error

Georg Brandl added the comment: Okay, fixed in r60317. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue1631394] sre module has misleading docs

Georg Brandl added the comment: Thanks, committed r60136. _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue1934] os.path.isabs documentation error

Giampaolo Rodola' added the comment: > Return ``True`` if *path* is an absolute pathname. On Unix, that > means it begins with a slash, on Windows that it begins with a > backslash after chopping off a potential drive letter. Actually the Windows part is not completely true since on Windows p

[issue1939] code object docstring obsolete

Georg Brandl added the comment: Committed r60313. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue1929] httplib _read_chunked TypeError ||| i = line.find(";")

Georg Brandl added the comment: Fixed in r60315. Thanks! -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1931] NameError: global name 'basestring' is not defined

Georg Brandl added the comment: I don't see why this shouldn't be closed. -- nosy: +georg.brandl status: pending -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1934] os.path.isabs documentation error

Georg Brandl added the comment: Fixed in r60314. Thanks for the report! -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __