[issue1789] assumption about unsigned long byte size in struct module usage

Gregory P. Smith added the comment: The giant patch was unnecessary, I misread what the struct module was actually doing. Auditing all uses of struct in the standard library the only ones that look suspicious to me are: Lib/posixfile.py and all of the uses in Lib/plat-mac/ posixfile is

[issue1976] pybsddb leak in using cursors

Gregory P. Smith added the comment: yes i'll take a look at this weekend. jcea is doing his bsddb development in the pybsddb.sf.net project svn repository for the time being. I'll be merging his changes back into the python tree. We can get him python svn access soon but i wanted to

[issue1976] pybsddb leak in using cursors

Gregory P. Smith added the comment: Fix committed as r60544 in trunk and r60545 in release25-maint. i assume it'll be merged into py3k in the regular py3k merge sweeps. -- resolution: -> accepted status: open -> closed versions: +Python 2.5,

[issue2054] add ftp-tls support to ftplib - RFC 4217

New submission from Gregory P. Smith: ftplib does not support ftp over SSL / TLS as described in RFC 4217. This would be a nice thing for someone wanting to contribute something to add. -- components: Library (Lib) messages: 62217 nosy: gregory.p.smith severity: normal status: open

[issue2016] Crash when modifying the **kwargs passed to a function.

Changes by Gregory P. Smith: -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2016> __ ___ Python-bugs-list mailing list Unsubs

[issue1404925] subprocess.Popen inside thread locks the thread in some case (2.4)

Gregory P. Smith added the comment: This appears to have been fixed in 2.5 and trunk. 2.4.x is old and in security fixes only mode so I wouldn't expect to see this in any official 2.4.x source tree released in the future unless the bdfl changes his mind on that. here's the patch to

[issue2227] time.strptime too strict? should it assume current year?

New submission from Gregory P. Smith: Some common python utilities had problems on Feb 29 this year when parsing dates using format strings that did not include a year in them. >>> time.strptime('Feb 29', '%b %d') Traceback (most recent call last): File &quo

[issue1397] mysteriously failing test_bsddb3 threading test in other threads

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I updated the subject to better reflect what this is. My guess is that the test code itself has issues and is asserting something that isn't quite guaranteed to be true. -- title: py3k-pep3137: failing unit test

[issue1202] zlib.crc32() and adler32() return value

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: working on this now. foo = 'abcdefghijklmnop' 2.x 32-bit long: zlib.crc32(foo) returns -1808088941 2.x 64-bit long: zlib.crc32(foo) returns 2486878355 This is because PyInt_FromLong() happily fits the value into a signed

[issue1202] zlib.crc32() and adler32() return value

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: question: should I also make 64-bit 2.x return a signed value as well to be consistent with 32bit python 2.x? Consistency in case someone ever pickles the value and sends it to another python instance of a different word length wo

[issue1202] zlib.crc32() and adler32() return value

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fixed. 3.0 always returns unsigned. 2.6 always returns signed, 2**31...2**31-1 come back as negative integers. trunk r61449 branches/py3k r61459 -- resolution: -> fixed status: open

[issue1747858] chown broken on 64bit

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: i'll take a look at this during the sprint. -- assignee: -> gregory.p.smith nosy: +gregory.p.smith _ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue1747858] chown broken on 64bit

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- versions: +Python 2.6, Python 3.0 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1747858> _

[issue1471] ioctl doesn't work properly on 64-bit OpenBSD

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: i'd say the patch is fine. on linux ioctl takes an int. on openbsd it takes an unsigned long. on something else it might even take its own type like an ioctl_t. regardless, treating the parameter as either a long or unsigne

[issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- keywords: +64bit title: ioctl doesn't work properly on 64-bit OpenBSD -> ioctl request argument broken on 64-bit OpenBSD or OS X __ Tracker <[EMAIL PROTECTED]> <http://bu

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: We really could use an automated pybench runner on a dedicated machine driven by a buildbot feeding its results into a database so that we had a record of exactly when/what caused performance changes over time. This sounds remarkabl

[issue1747858] chown broken on 64bit

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fixed in trunk r61540. I'm leaving this open until i backport it to release25-maint. -- resolution: -> remind versions: -Python 2.6 _ Tracker <[EMAIL PROTECTED]> <

[issue1747858] chown broken on 64bit

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: backported to 2.5 in r61542 and r61544. it'll go into py3k via the regular merges from trunk. The fix just changed the int -> long and 'ii' -> 'll' and added unit test coverage. The patch attached to

[issue2426] pysqlite provides no interface for database SQL dump

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I am unable to reproduce this problem at all on Mac OS X 10.4 or 10.5 with 32-bit or 64-bit python trunk builds. I have however checked in a fix that'll prevent negative code values passed in from being sign extended to 6

[issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: r61665 moves the test to test_ioctl instead of test_fcntl. it also forces it to only run when a pty is present rather than assuming fd 0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1657] [patch] epoll and kqueue wrappers for the select module

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: +1 trunk_select_epoll_kqueue9.patch looks good to me. style nit: I'd just use self.fail("error message") instead of raise AssertionError("error message") within unittests. regardless, both work so I

[issue2329] ImportError: No module named _bsddb

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: BerkeleyDB is detected when make runs setup.py. Look in the output from your make and you'll see a message about whether or not a useful BerkeleyDB library and include files were found. Typically this happens on linux dist

[issue2320] Race condition in subprocess using stdin

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2320] Race condition in subprocess using stdin

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: This is easily reproducable on my OS X 10.4 macbookpro. However your suggested two lines with the os.pipe to lock to prevent the problem are a red herring... Locking those does not fix it. __ T

[issue1731717] race condition in subprocess module

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: """Basically it's OK to collect all the child exit codes if you record the results and return them when requested. This would mean that waitpid and the like would have to check a cached list of PIDs and exit status

[issue1731717] race condition in subprocess module

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I am unable to reproduce this problem in today's trunk (2.6a) on OSX 10.4. _ Tracker <[EMAIL PROTECTED]> <http://bugs.pyt

[issue2381] test_subprocess fails if your sys.executable is on a path with a space in it

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith keywords: +easy nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2454] md5 fixer

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: And do the same for: sha.sha1 -> hashlib.sha1 sha.new -> hashlib.sha1 -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm attaching a slightly improved version of the longfreelist2 patch. It moves the important test to be first and removes the unneeded ? : conditional. Here are some more

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Looking at how much memory was actually used by PyLongObjects the way our code allocates them... we can use this freelist for 2 digit PyLongs on 32-bit systems and for 4 digit PyLongs on 64-bit systems. Doing this speeds things u

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: And the benchmarks of gps02... see the attached file. At the end I had it run pybench rather than these microbenchmarks that obviously show the speedup, the -gps02 patch ran 1.3% faster best case a 0.5% faster on average (32-bit; my

[issue1202] zlib.crc32() and adler32() return value

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The workaround I prefer to use is: x = zlib.adler32(mystr) & 0xL __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1731717] race condition in subprocess module

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fwiw, I see pids cycle in a reasonable amount of time on modern production linux systems today. its a fact of life, we should deal with it. :) _ Tracker <[EMAIL PROTECTED]> <http://

[issue2459] speedup loops with better bytecode

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2459> __ ___ Python-bugs

[issue2429] Patch for test_urllib2_net moving tests to use a local server

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2429] Patch for test_urllib2_net moving tests to use a local server

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: committed to trunk in r61998. time to watch the buildbots, it looked good to me and passed on my machine. i'll close it once i see buildbot test love. tweaks i made: I reenabled the commented out ProxyAuth test, as it

[issue2426] pysqlite provides no interface for database SQL dump

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: thanks! committed to trunk in r62000. -- priority: -> normal resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://b

[issue2426] pysqlite provides no interface for database SQL dump

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: and r62012 which adds the dump.py files I forgot to svn add in r62000. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2426] pysqlite provides no interface for database SQL dump

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: although closed, i'm assigning this to ghaering so that he knows it went in and can merge this back into pysqlite if its not already in there. -- assignee: gregory.p.smith -> ghaering n

[issue2464] urllib2 can't handle http://www.wikispaces.com

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The problem does not appear to have anything to do with SSL. The problem is that the chain of HTTP requests goes: GET -> 302 -> 302 -> 301 On the final 301 urllib2's internal state is messed up such that by

[issue2464] urllib2 can't handle http://www.wikispaces.com

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Instrumenting the code and looking closer at the tcpdump, its true. wikispaces.com is returning an invalid Location: header with a null byte in the middle of it. The "fix" on our end should be to handle such garbage from

[issue2464] urllib2 can't handle http://www.wikispaces.com

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm not sure what the best solution for this is. If I truncate the header values at a \x00 character it ends in an infinite redirect loop (which urllib2 detects and raises on). If I simple remove all \x00 characters the resul

[issue2429] Patch for test_urllib2_net moving tests to use a local server

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: all buildbots seem happy with the new tests. -- status: pending -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue1068268] subprocess is not EINTR-safe

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1068268> _ __

[issue2538] memoryview of bytes is not readonly

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2538> __ ___ Python-bugs

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: agreed, do not check to see if the string is == 'gcc'. Instead, actually execute the CC compiler with a -v flag and test if 'gcc version' in output. something like this (but split into a few statements for read

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm reviewing this patch now and plan to commit it after some testing. A couple comments: I'd rename your sts variables to status. Also FYI: Your use of volatile on the int unlocked_count member of PyFileObject does

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I've attached my patch that I want to commit. The main change from filethread4 is some cleanup in file_test to make it run a lot faster and add verbose mode output to indicate how well it is actually testing the problem (countin

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Committed to trunk in revision 62195. Misc/NEWS entry added. I also added two new C API functions: PyFile_IncUseCount and PyFile_DecUseCount along with documentation. They should be used by any C extension code that uses PyFile_

[issue595601] file (& socket) I/O are not thread safe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Fix committed to trunk in revision 62195 via Issue 815646 Tracker <[EMAIL PROTECTED]> <http://bugs.python.

[issue2538] memoryview of bytes is not readonly

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: This patch looks good. One question: in Objects/abstract.c in PyBuffer_FillInfo, why is it even testing for the PyBUF_LOCK flag at all? PEP 3118 says its valid for both reading and writing (if the underlying object supports locked

[issue2576] httplib read() very slow due to lack of socket buffer

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- priority: -> high __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2576> __ ___ Python-b

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: agreed, the assert in PyString_FromStringAndSize() should be changed to a non-debug test. -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- priority: -> high versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2587> __ __

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I think I like the SystemError approach for the same reasons. It still exposes the caller's bug but no longer does bad things. Added file: http://bugs.python.org/file9994/unnamed __ Trac

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2587> __ ___

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9994/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2587> __

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: python trunk r62261 adds the checks and SystemError. patches to cleanup modules that inadvertently allow negative values to be passed into *_FromStringAndSize would still be appreciated. __ Tracker &

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: release25-maint r62262 I'm closing this one. Please open additional issues with patches and/or pointers to bad callers of *_FromStringAndSize that let negative values through. [*sigh* i wish we didn't use a signed size t

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The asserts can go. I left them in figuring a crashing interpreter on a debug build in someones sandbox or on a buildbox would get more attention than a SystemError being raised. I doubt that is a worthy assumption on my part.

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: asserts nuked. r62271 and r62272 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2587> __ ___ Python

[issue2620] Multiple buffer overflows in unicode processing

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith priority: -> high versions: +Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue1481036] IOBaseError

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I don't think so. socket.error has been changed to inherit from IOError in 2.6 (and thus socket.sslerror which inherits from socket.error). EOFError has not changed. ftplib.all_errors is already a tuple of (ftplib.Error, s

[issue1481036] IOBaseError

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- resolution: fixed -> status: closed -> open _ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue1481036] IOBaseError

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The problem with EOFError as a child of EnvironmentError is that it wouldn't conform to EnvironmentError's standard 2-tuple or 3-tuple of args representing errno and the associate string and optionally filename. So insert

[issue2620] Multiple buffer overflows in unicode processing

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2629] _Py_ForgetReference crash when called from _PyUnicode_New on MemoryError

New submission from Gregory P. Smith <[EMAIL PROTECTED]>: In _PyUnicode_New() a unicode object is taken from the freelist but if the unicode_resize() call fails and returns -1, the goto onerror calls _Py_ForgetReference on the unicode object... But it has NULL _ob_prev and _ob_next

[issue2620] Multiple buffer overflows in unicode processing

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Here's a patch that fixes this by making both Python's malloc and realloc return NULL if (0 <= size <= PY_SSIZE_T_MAX). A side effect of this is that strings on 32bit platforms can no longer be allocated up to 2*

[issue1092502] Memory leak in socket.py on Mac OS X

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1092502> _ __

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I don't think the fix was acceptable. Now python spins consuming all cpu trying to read trivial amounts of data one byte at a time... See the discusson at the end of http://bugs.python.org/issue1092502 as well as a recent

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: or else i'm missing something here in the maze of three bugs talking about the same issue.. which revisions fixed the introduced performance issue? __ Tracker <[EMAIL PROTECTED]> <ht

[issue2645] httplib throws ValueError

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: thanks for the patch. can you check the HTTP/1.1 RFC and see what it says (if anything) about handling this case? also, do you happen to get this consistently from any particular urls or servers or is this pretty random just hap

[issue2652] 64 bit python memory leak usage

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2652> __ ___ Python-bugs

[issue2645] httplib throws ValueError

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: could you backport that to release25-maint if it isn't there already? __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2632] performance problem in socket._fileobject.read

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Twisted fixed their problem for issue 1092502 by making recv()ed data short lived by putting it into a StringIO for buffering. I've attached a patch that does that for the socket module -and- gets rid of any possibility of doin

[issue2632] performance problem in socket._fileobject.read

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: available for an easy side by side review here: http://codereview.appspot.com/212 Also, yes I think you're right Ralf. With these changes I should be able to return that to a max() within the while True: for sized reads and

[issue2632] performance problem in socket._fileobject.read

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I fixed the min vs max use that Ralf noted and have submitted this as r62627. all tests pass for me but I believe it deserves a wider audience and testing outside of just the test suite. could those who reported the original pr

[issue2632] performance problem in socket._fileobject.read

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- priority: critical -> release blocker __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2632> __ __

[issue2722] os.getcwd fails for long path names on linux

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- keywords: +easy nosy: +gregory.p.smith priority: -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2158] confusing exception when opening a filename with nonprintable characters

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: backported r61468 to release25-maint in r62659. -- assignee: -> gregory.p.smith resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://b

[issue2760] Recent change in socket.py breaks urllib2

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: the change in socket was done as part of #2632. i'm marking this a duplicate, we'll track the issue in #2632. -- assignee: -> gregory.p.smith dependencies: +performance problem in socket._fileobject.read nos

[issue2632] performance problem in socket._fileobject.read

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm glad i put that assert in... The problem occurs due to a mixture of fixed size reads followed by unbounded readlines on an unbuffered _fileobject. A case that the code currently doesn't handle

[issue2632] performance problem in socket._fileobject.read

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The bug introduced in r62627 has been fixed in r62744. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2760] Recent change in socket.py breaks urllib2

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The bug introduced in r62627 has been fixed in r62744. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2707] Tiny fix for os.walk docstring

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fixed in trunk r62756 and release25-maint r62757. thanks for the report. -- assignee: -> gregory.p.smith keywords: +easy nosy: +gregory.p.smith resolution: -> fixed status: open -> closed versio

[issue2628] ftplib Persistent data connection

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: rather than using the array.array for your three byte header with manual parsing, please use struct.unpack. Whats a good way to test that this works? It'd be nice to have a unit test (a test_ftplib_net.py perhaps?) though I rea

[issue2723] Truncate __len__() at sys.maxsize

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Agreed, having it lie about the size is the WORST possible behavior because it will silently hide problems. Lets not do that. But I must've missed something, why can't __len__ return the correct value? Merely because r

[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: looks like it already has been merged in py3k. -- versions: +Python 2.5.3 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: oh yay, thanks. it looks like you did approximately what i had started working on testing a while back but have gone much further and added autoconf magic to try and determine when which size should be used. good. (i haven'

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I agree with Christian that we should wait until 3.0 is out. Using A DVCS should make this much easier if anyone needs an excuse to learn bzr. I think we should aim to commit the 30bit change (a pretty clear win by the looks of

[issue4194] default subprocess.Popen buffer size

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: If anything for 2.6 lets just highlight this in the docs and mention that bufsize needs to be set to non-zero for good performance on many platforms such as Mac OS X and Solaris. We can consider changing the default for 2.7/3.1

[issue2628] ftplib Persistent data connection

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: sure go for it, i haven't had time to look at the latest patch myself. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.

[issue4448] should socket readline() use default_bufsize instead of _rbufsize?

New submission from Gregory P. Smith <[EMAIL PROTECTED]>: From Kristján Valur Jónsson (kristjan at ccpgames.com) on python-dev: http://mail.python.org/pipermail/python-dev/2008-November/083724.html I came across this in socket.c: # _rbufsize is the suggested recv

[issue1683] Thread local storage and PyGILState_* mucked up by os.fork()

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: gregory.p.smith -> christian.heimes ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3826] BaseHTTPRequestHandler depends on GC to close connections

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- keywords: +patch Added file: http://bugs.python.org/file12151/issue3826_socketserver-gps01.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3826] BaseHTTPRequestHandler depends on GC to close connections

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file12152/issue3826_socket-gps01.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3826] BaseHTTPRequestHandler depends on GC to close connections

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Alright I've taken another fresh look at this. I understand the dup semantics issue and don't want to break that. Attached are two patches, either one of these will fix the problem and breakage.py test code atta

[issue3826] BaseHTTPRequestHandler depends on GC to close connections

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: P.S. Gabriel Genellina (gagenellina) - Your comment sounded like you had a unit test for this but it never got attached. Still have it? -- stage: -> patch review ___ Python tracke

[issue3826] BaseHTTPRequestHandler depends on GC to close connections

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file12153/issue3826_socket-gps02.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

<    2   3   4   5   6   7   8   9   10   11   >