[issue1539] test_collections: failing refleak test

Changes by Guido van Rossum: -- priority: normal -> high __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1539> __ ___ Python-bugs-list mailing li

[issue1540] Refleak tests: test_doctest and test_gc are failing

Guido van Rossum added the comment: Hoping to draw Tim into this... He's the only one I know who truly understands these issues... -- assignee: -> tim_one nosy: +tim_one __ Tracker <[EMAIL PROTECTED]> <http://bugs.pyt

[issue1326] "internal" zipimport.zipimporter feature untested

Guido van Rossum added the comment: Which Python version is this for? -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1326> __ ___

[issue1067] test_smtplib failures (caused by asyncore)

Guido van Rossum added the comment: OK, closing. I see plenty of mention of these two modules in the lists, so maybe someone else wants to take a whack at it. I'll post to python-dev. -- keywords: +py3k nosy: -nobody priority: high ->

[issue1336] subprocess.Popen hangs when child writes to stderr

Guido van Rossum added the comment: I'm sorry to ask you to do more work, but could you do me a favor and send this in the form of a svn diff? That file has evolved quite a bit and it's unclear what version you used as a baseline. -- keywor

[issue1400] Py3k's print() flushing problem

Guido van Rossum added the comment: Committed revision 59379. This adds proper line_buffering behavior. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1559] round() does not

Guido van Rossum added the comment: travelgirl: the 'decimal' module is designed to deal with this. Note that there's a difference between BCD (which can represent decimal numbers exactly) and binary (which can't, in general).

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I get a segfault when I run it like this: $ ./python.exe Lib/test/regrtest.py -uall test_ssl test_ssl Segmentation fault $ (Without -uall it passes.) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I will look at this in an hour or so, after I bring Orlijn to school and drive to work. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: Oops, I just committed revision 59394. Please advise. -- priority: high -> immediate __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I just reverted it. I put a bit of debugging in the call to _real_close(), and even with Christian's corrections it fails miserably. I prefer leaking. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I'm giving up on this for now. There are other weird bugs in the code, e.g. this simple piece of code fails: >>> x = urllib.urlopen("https://mail.google.com";).read() Traceback (most recent call last): File "", line 1,

[issue1564] The set implementation should special-case PyUnicode instead of PyString

Changes by Guido van Rossum: -- keywords: py3k nosy: gvanrossum severity: normal status: open title: The set implementation should special-case PyUnicode instead of PyString versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1564] The set implementation should special-case PyUnicode instead of PyString

Guido van Rossum added the comment: Would it make any sense at all to refactor the code so that code reuse is automatic? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1469] SSL tests leak memory

Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8892/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1469> __ ___ Python-bugs-list

[issue1570] Backport sys.maxsize to Python 2.6

Guido van Rossum added the comment: Maybe suggest this as a GHOP task? -- nosy: +gvanrossum priority: high -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: Don't worry, I did back it out before releasing 3.0a2. I believe I hacked your code a bit before checking it in (or after you checked it in, can't remember). Did you see my bug report with a TypeError? __ Track

[issue1469] SSL tests leak memory

Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8845/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1469> __ ___ Python-bugs-list

[issue1564547] Py_signal_pipe

Guido van Rossum added the comment: I've been told to look at this one more time. -- assignee: -> gvanrossum nosy: +gvanrossum resolution: rejected -> status: closed -> open _ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue1572] 404 report of SimpleXMLRPCServer is broken

Guido van Rossum added the comment: Is disabling a test the right solution? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1572> __ __

[issue1560] PATCH: Attribute lookup caching

Guido van Rossum added the comment: Are you withdrawing this in favor of #1568? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1577] shutil.move() does not use os.rename() if dst is a directory

Guido van Rossum added the comment: We should first decide what should happen. While for command line tools "mv FILE DIR" is established syntax for "mv FILE DIR/`basename FILE`", I'm not at all sure that shutil.move(src, dst) should do the same. I think it sho

[issue1677872] Efficient reverse line iterator

Guido van Rossum added the comment: I'd like to see the doc patches separated out and applied to 2.6 -- they'll automatically merge into 3.0 then. Make that a separate bug please. I like the idea, haven't had time to carefully review the code, but noticed one oddity: >>&

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

Guido van Rossum added the comment: How about, in Python 2.6 we make the 64-bit version return a signed value for better compatibility with the 32-bit version, and in Python 3.0 we make both versions return the signed value for better compliance with the standard

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: I like this; but I don't have time for a complete thourough review. Maybe Tim can lend a hand? If Tim has no time, I propose that if it works correctly without leaks on at least Windows, OSX and Linux, we check it in, and worry about more review later.

[issue1560] PATCH: Attribute lookup caching

Changes by Guido van Rossum: -- resolution: -> out of date status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1560> __ __

[issue1560] PATCH: Attribute lookup caching

Guido van Rossum added the comment: That's still ambiguous -- do you want any of those to be closed too? Clearly we're not going to patch 2.4. __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1581] xmlrpclib.ServerProxy() doesn't use x509 data

Guido van Rossum added the comment: This should be considered for 2.6, not 2.5 (which is in feature freeze). I'm hoping Bill Janssen can review this. -- assignee: -> janssen nosy: +gvanrossum, janssen __ Tracker <[EMAIL PROTEC

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

Guido van Rossum added the comment: > Obscure but reasonable. (I suspect you meant to say that py3k should > return the *unsigned* value for better compliance with the standard.) Yes. :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1643738] Problem with signals in a single-threaded application

Guido van Rossum added the comment: Discussing this with Rhamporyncus (Adam Olson) on #python-dev now. -- assignee: -> gvanrossum nosy: +gvanrossum _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1643738] Problem with signals in a single-threaded application

Guido van Rossum added the comment: Committed revision 59460 to 2.6. Will backport to 2.5 as well. -- resolution: -> accepted _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1643738] Problem with signals in a single-threaded application

Guido van Rossum added the comment: Committed revision 59461 to 2.5. Thanks, Ulisses!! -- status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: > So, what's the final status of __del__ in py3K? The other bit of leak > is due to _real_close() not being called when a socket is dropped on the > floor (say, you try to connect, fail, and raise the exception back to > the caller, withou

[issue1582] Documentation patch for reversed() and __reversed__()

Guido van Rossum added the comment: Georg, can you handle this? -- assignee: -> georg.brandl nosy: +georg.brandl, gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1583] Patch for signal.set_wakeup_fd

Guido van Rossum added the comment: Thanks! Can you add a doc patch too? Doc/library/signal.rst -- assignee: -> gvanrossum keywords: +py3k versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I wonder if Christian Heimes was correct that the ssl object needs GC support? This was part of his patch (which I checked in and then reverted because the other part of it didn't work as advertised). Alternatively, if 's' is involved in a cyc

[issue1583] Patch for signal.set_wakeup_fd

Changes by Guido van Rossum: -- priority: -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583> __ ___ Python-bugs-list mailing list Uns

[issue1583] Patch for signal.set_wakeup_fd

Changes by Guido van Rossum: -- keywords: +patch -py3k __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583> __ ___ Python-bugs-list mailing list Unsubs

[issue1564547] Py_signal_pipe

Guido van Rossum added the comment: Rejected, in favor of #1583 which lets the app choose whether to use a fd or not. We had an extensive #python-dev discussion on this and this time the rejection is irrevocable. -- resolution: -> accepted status: open ->

[issue1564547] Py_signal_pipe

Changes by Guido van Rossum: -- resolution: accepted -> rejected superseder: -> Patch for signal.set_wakeup_fd _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: Noam, perhaps you can help with this? We checked this in but found a problem: repr(1e5) suddenly returns '1.0'. Can you think of a cause for this? -- status: closed -> open __ Tracker <[EMAIL P

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > On what platform does it happen? Linux on x86. It seems find on PPC OSX. This suggests it could be a byte order bug. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: (1) Despite Tim's grave language, I don't think we'll need to write our own correctly-rounding float input routine. We can just say that Python won't work correctly unless your float input routine is rounding correctly; a unittest should

[issue1577] shutil.move() does not use os.rename() if dst is a directory

Guido van Rossum added the comment: > Since we already have os.rename, wouldn't it be better for shutil.move() > to be closer to command line 'mv'? I think Facundo's approach should work. I'd rather not do this. It might cause disasters for code that expects the o

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > > (1a) Perhaps it's better to only do this for Python 3.0, which has a > > smaller set of platforms to support. > > +1 > Does Python depend on a working, valid and non-broken IEEE 754 floating > point arithmetic? Could we

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

Guido van Rossum added the comment: Bill, can you respond? -- assignee: -> janssen nosy: +gvanrossum, janssen __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1587] instancemethod wrapper for PyCFunctions

Guido van Rossum added the comment: I'm tempted to call YAGNI on this. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1587> __ __

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: This really is a feature request -- in Python 2.x there is no formatting code for complex numbers at all, and "%.5s" % complex(...) does the same thing. I agree it would be neat to have control over complex numbers using the same formatting languag

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: Maybe this would be a good GHOP task? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1588> __ ___ Python-bugs-list

[issue1590] "make altinstall" installs pydoc, idle, smtpd.py

Guido van Rossum added the comment: Agreed. Please provide a patch. Isn't this a 2.5-2.6 issue as well? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > Do you know of any system that supports Python and floats but doesn't have IEEE 753 semantics? (Assuming you meant 754.) I'm pretty sure the VAX doesn't have IEEE FP, and it used to run Unix and Python. Ditto for Crays -- unsure if we

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > Correct rounding is a property that needs to be proved, not tested. I take it your position is that this can never be done 100% correctly so it shouldn't go in? That's disappointing, because the stream of complaints that "round is brok

[issue1587] instancemethod wrapper for PyCFunctions

Guido van Rossum added the comment: OK, you've convinced me. Let's just make it a C API for now. On Dec 11, 2007 10:56 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > The wrapper is useful for C code which used PyMethod_Ne

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: I'd be willing to require eval(repr(x)) == x only for platforms whose float input routine is correctly rounding. That would make the current patch acceptable I believe -- but I believe you think there's a better way in that case too? What way is t

[issue1596] Broken pipes should be handled better in 2.x

Guido van Rossum added the comment: I'll entertain a patch for 2.6. For 2.5 I think this smells too much like a feature. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: Sounds okay, except that I think that for some folks (e.g. numeric Python users) I/O speed *does* matter, as their matrices are very large, and their disks and networks are very fast. __ Tracker <[EMAIL PROTECTED]>

[issue1597] running test_ctypes 25 times in a row causes it to fail

New submission from Guido van Rossum: In debug mode, on my Ubuntu Linux box, this fails on the last iteration: $ ./python Lib/test/regrtest.py -R:20 test_ctypes test_ctypes beginning 25 repetitions 1234567890123456789012345 test test_ctypes failed -- Traceback (most

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > If I were in that situation I would prefer to store the binary > representation. But if someone really needs to store decimal floats, > we can add a method "fast_repr" which always calculates 17 decimal > digits. They can just use &qu

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: I've tracked my problem to the GCC optimizer. The default optimizer setting is -O3. When I edit the Makefile to change this to -O1 or -O0 and recompile (only) doubledigits.c, repr(1e5) starts returning '10.0' again. -O2 behaves the same as -

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: > I thought Python 3 was meant to be an _improvement_:-) That's why I didn't close the issue but reclassified it. Or did you expect me to implement it overnight? :-) __ Tracker <[EMAIL PROTECTED]> <

[issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1)

Changes by Guido van Rossum: -- assignee: -> kbk nosy: +kbk __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1601> __ ___ Python-bugs-list mailing li

[issue1600] str.format() produces different output on different platforms (Py30a2)

Guido van Rossum added the comment: Again, a (not unreasonable) feature request. AFAIK %e behaves the same way. I'm sure if you submitted a patch it would be accepted happily. -- nosy: +gvanrossum priority: -> normal __ Tracker <[EMAI

[issue1604] collections.deque.__init__ doesn't initialize

Guido van Rossum added the comment: I agree, I put the list behavior in on purpose. Should be fixed in 2.6, not 2.5 though, since it's a feature. -- assignee: -> rhettinger nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http:

[issue1597] running test_ctypes 25 times in a row causes it to fail

Guido van Rossum added the comment: Thanks! (I agree with Eric Smith that this is mysterious for the innocent bystander.) Also, what about the -33/+33 leaks? I suppose these are harmless, but it would be better if the test reliably didn't report leaks... -- resolution: -&g

[issue1597] running test_ctypes 25 times in a row causes it to fail

Guido van Rossum added the comment: > The minimal code reporting the -33/+33 leaks that I found is simply this: > >os.popen('ls').read() > > Is there a problem in "os.popen(...)", or do I something wrong here? Try this instead: p = os.popen('ls'

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: > Ok, so if I understand correctly, the ideal thing would be to > implement decimal to binary conversion by ourselves. This would make > str <-> float conversion do the same thing on all platforms, and would > make repr(1.1)=='1.1'.

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: Why not simply reverse the wait() and read() calls? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1605] Semi autogenerated _types module

Guido van Rossum added the comment: But what about static type objects that nevertheless may be exposed to Python (e.g. dict_keyview?). -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> __ ___ Python-bugs-list mailing list Unsubs

[issue1612] infinite recursion when using collections.Sequence in a recursive function (Py30a2)

Guido van Rossum added the comment: The bug is in your code; a string is considered a sequence but its elements are also strings (of length 1). -- nosy: +gvanrossum resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTE

[issue1609] test_re.py fails

Guido van Rossum added the comment: Can't reproduce. Like before, what platform, compiler etc.? Does using ./configure --with-pydebug make a difference? What's the LD_LIBRARY_PATH for? -- nosy: +gvanrossum __ Tracker <[EMAIL PROT

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: > > Why not simply reverse the wait() and read() calls? > > I don't think it is sufficient if the user uses more than one pipe. The > subprocess.communicate() and _communicate() methods are using threads > (Windows) or select (Unix)

[issue1608] test_str.py crashes

Guido van Rossum added the comment: What hardware and OS? 32 or 64 bit? What optimization level? Debug build or not? NB. Unless you used /Misc/valgrind-python.supp, the valgrind output is useless. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTEC

[issue1611] doctest.testmod gets noisy if called more than once per SystemExit

Guido van Rossum added the comment: I suspect that doctest was simply not intended to be used this way. Maybe Tim remembers more? -- assignee: -> tim_one nosy: +gvanrossum, tim_one __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue1613] Makefile's VPATH feature is broken

Guido van Rossum added the comment: Before I try to reproduce this, I remember having problems when switching between using VPATH and not using it in the same subversion workspace. The .o files left behind by one version confuse the other. -- nosy: +gvanrossum

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Looks like expandtabs() has a problem. Can you boil it down to a single call? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1608] test_str.py crashes

Guido van Rossum added the comment: BTW is this a released version of GCC? If not, you might want to file the bug with the GCC project... __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1614] bug in string method "title"

Guido van Rossum added the comment: That's not going to change. -- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue1609] test_re.py fails

Guido van Rossum added the comment: > Without LD_LIBRARY_PATH it would use the system libraries and not the > compiled ones which anyway is not wanted. What system libraries? Does it make a difference if you don't specify either of --enable-unicode=ucs4 \ --with-wctype-functions

[issue1613] Makefile's VPATH feature is broken

Guido van Rossum added the comment: Do you need more help at this point? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1613> __ ___ Python-bugs-list

[issue1608] test_str.py crashes

Guido van Rossum added the comment: > This is a soon to be released GCC though I won't deny it has > regressions, but note that extra optimizations already uncovered bugs in > other software. And the GCC authors always win these cases, C standard in hand. > And unless I ca

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Actually, looking at the sample code and the string_expandtabs() implementation it's clear what happened: the test for overflow on line 3318 or 3331 or 3339 must have been optimized out by GCC. This is very inconvenient because lots of buffer ove

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Martin, can you look into this? It seems GCC 4.3 disables buffer overflow protection checks. The best short-term solution may be to disable that particular kind of optimization. How? __ Tracker <[EMAIL PROTECTED]>

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Martin, can you look into this? It seems GCC 4.3 disables buffer overflow protection checks. The best short-term solution may be to disable that particular kind of optimization. How? -- assignee: -> loewis nosy: +loe

[issue1608] test_str.py crashes

Guido van Rossum added the comment: > if you can give me a sample testcase I can bug GCC developers, this > doesn't look good from GCC side at all. Btw from my limited C knowledge > marking variables would volatile would prevent optimizations of them. The example would be someth

[issue1608] test_str.py crashes

Guido van Rossum added the comment: > Ok so this is a code bug according to GCC developers see comment 1 & 2 > at http://gcc.gnu.org/PR34454 . I told you you can't win this argument with the GCC devs. We'll have to use -fwrapv or whatever. __

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Can you suggest a patch that adds this permanently, whenever it is supported? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1608] test_str.py crashes

Guido van Rossum added the comment: GCC 2.96 is still the golden standard for me, and it doesn't like -fwrapv. Please try to come up with a better patch. It should be easy enough to invoke gcc -fwrapv with a dummy program. __ Tracker <[EMAIL PROTECTED

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: Hm, when I run the full test_ssl test suite with ./python Lib/test/regrtest.py -v -uall test_ssl it always hangs in testAsyncoreServer after printing this: testAsyncoreServer (test.test_ssl.ThreadedTests) ... server: new connection from 127.0.0.1:59781

[issue1616] compiler warnings (gcc 2.96)

New submission from Guido van Rossum: I figured this would be useful: /home/guido/p25/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/guido/p25/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Committed revision 59483 (2.5 branch). Committed revision 59484 (2.6 trunk). Keeping this open since someone still needs to run autoconf to regenerate configure for the 2.6 trunk. -- priority: urgent -> nor

[issue1617] Rare exception in test_urllib2net

New submission from Guido van Rossum: test test_urllib2net failed -- Traceback (most recent call last): File "/tmp/python-test/local/lib/python2.6/test/test_urllib2net.py", line 175, in test_ftp self._test_urls(urls, self._extra_handlers()) File "/tmp/python-test/local/lib

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: > I believe so, too. The subprocess docs aren't warning about the problem. > I've seen a fair share of programmers who fall for the trap - including > me a few weeks ago. Yes, the docs should definitely address this. > Consider yet ano

[issue1617] Rare exception in test_urllib2net

Guido van Rossum added the comment: Can you log in to the box and reproduce it manually? On Dec 13, 2007 1:49 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > Neal Norwitz added the comment: > > This may happen every time on the MIPS buildbot. Here is a recent run. > > h

[issue1608] test_str.py crashes

Guido van Rossum added the comment: Thomas Heller ran autoconf for the trunk and submitted as r59485. (Thomas, could you run it in the 2.5 branch as well? I seem to have checked in a lot of gratuitous changes by using an older version of autoconf.) -- nosy: +theller resolution

[issue1608] test_str.py crashes

Guido van Rossum added the comment: > """code that has been audited and fixed in the past will again be > vulnerable.""" > > That code wasn't properly audited or fixed if it depended on integer > overflow behavior. Whatever, this is how over

[issue1622] zipfile hangs on certain zip files

Changes by Guido van Rossum: -- keywords: +patch nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: > Good catch. I flipped a bit cleaning up the C code. > > Here's a fixed patch. > > Added file: http://bugs.python.org/file8949/patch-3 Great! Go ahead and check it in. Sorry for deleting the _real_close() earlier BTW.

[issue1469] SSL tests leak memory

Guido van Rossum added the comment: I spoke too soon. In a debug build, this hangs forever during the second iteration: ./python.exe Lib/test/regrtest.py -uall -R1:1 test_ssl Adding -v, it looks like two iterations are carried out perfectly (one must be a trial run, one the warm-up run), but

[issue1624] Remove output comparison for test_pep277

Guido van Rossum added the comment: Crys, can you look into this? -- assignee: -> tiran keywords: +patch nosy: +gvanrossum, tiran __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

<    7   8   9   10   11   12   13   14   15   16   >