[issue2065] trunk version does not compile with vs8 and vc6

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9873/ocean.zip __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bug

[issue2065] trunk version does not compile with vs8 and vc6

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9595/ocean.zip __ Tracker <[EMAIL PROTECTED]> __ ___ Python-b

[issue2065] trunk version does not compile with vs8 and vc6

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9577/ocean.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue2065] trunk version does not compile with vs8 and vc6

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9456/ocean.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue2065] trunk version does not compile with vs8 and vc6

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9424/ocean.zip __ Tracker <[EMAIL PROTECTED]> __ ___ Python-b

[issue2459] speedup loops with better bytecode

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Antoine, I hope to look at this patch eventually. Unfortunately, there are too many build/test problems that need to be resolved before the next release. If you can help out with those, I will be able to review this patch sooner. -- n

[issue1622] zipfile hangs on certain zip files

Eric Huss <[EMAIL PROTECTED]> added the comment: Sorry for the long delay. Yes, the latest patch looks very good to me. -Eric __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2422] Automatically disable pymalloc when running under valgrind

James Henstridge <[EMAIL PROTECTED]> added the comment: An updated version of the patch. The previous ones were missing the valgrind check, resulting in the pymalloc code paths being executed (which in turn cause unintialised read warnings from valgrind). Added file: http://bugs.python.org/fil

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: There are similar problems with integer shifts. In the trunk: >>> 1>>(2**40) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int and in Python 3.0: >>> 1>>(2**40) Traceback (most re

[issue2459] speedup loops with better bytecode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Ok, the fix for the bizarre failures was really simple. Now the only failing tests are in test_trace (because it makes assumptions regarding the bytecode that aren't true anymore, I'll have to adapt the tests). Added file: http://bugs.python.

[issue2459] speedup loops with better bytecode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: This new patch completes the bytecode modifications. For/while loops as well as list comprehensions and generator expressions are a bit faster now. Also, as a side effect I've introduced a speed improvement for "if" statements and expressions.

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: With the following diff, test_xmlrpc.py passes without problems. Like I said, someone else should decide where to turn on blocking mode. I now think that it should be in the socket.accept (i.e. in the C code) at least for unix platforms. Those

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: No, please do not disable them. I'm not quite sure what to do, but apparently these sockets returned from accept should be turned into blocking sockets. I just do not know, where this should happen. I think that this could even be done inside th

[issue1503] test_xmlrpc is still flakey

Alan McIntyre <[EMAIL PROTECTED]> added the comment: It's my fault the xmlrpc tests try to use non-blocking sockets. That got added because sometimes failing tests would just sit there with the server blocking until the entire test process got killed for running too long. There are some tests t

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: now that I see that the buildbot was running on ppc *Debian* I'm not quite sure if we're talking about the same issue. __ Tracker <[EMAIL PROTECTED]> ___

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: I just double checked with the following program: #! /usr/bin/env python import os import fcntl import socket def isnonblocking(fd): return bool(fcntl.fcntl(fd, fcntl.F_GETFL, 0) & os.O_NONBLOCK) def main(): s=socket.socket()

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: The current buildbot has errors similar to this one (I assume): Exception happened during processing of request from ('127.0.0.1', 53126) Traceback (most recent call last): File "/Users/ralf/trunk/Lib/SocketServer.py", line 281, in _handle_re

[issue2458] Allow Python code to change Py3k warning flag

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Raising priority so this is looked at before we release 2.6. :) -- priority: -> critical __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1413192] bsddb: segfault on db.associate call with Txn and large data

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Uns

[issue2268] Fold slice constants

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Just to quantify the improvement: Before: $ ./python -m timeit -s"x='abc'" "x[::-1]" 100 loops, best of 3: 0.305 usec per loop $ ./python -O -m timeit -s"x='abc'" "x[::-1]" 100 loops, best of 3: 0.275 usec per loop After: $ .

[issue2490] Assertion failure in datetime.strftime()

Georg Brandl <[EMAIL PROTECTED]> added the comment: Okay, closing as out of date. -- resolution: -> out of date status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1222721] tk + setlocale problems...

ghorvath <[EMAIL PROTECTED]> added the comment: Attached a workaround for this problem, based on: http://ml.osdir.com/games.mud.client.lyntin/2005-03/msg5.html I also found that the problem only appears when the LC_NUMERIC setting is different to en_US. (for example if it is de_AT) Added fi

[issue1518] Fast globals/builtins access (patch)

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue2493] Remove unused constants from optimized code objects

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I've noticed that the original patch does not handle the error condition from failed consts resize correctly. Please see compress-consts-1.diff for a fix. Added file: http://bugs.python.org/file9868/compress-consts-1.diff __

[issue1222721] tk + setlocale problems...

ghorvath <[EMAIL PROTECTED]> added the comment: I can confirm that this bug is still present. After locale.setlocale(locale.LC_ALL, '') Backspace in Tkinter.Entry is not working anymore. There is no difference if the Backspace is issued by the keyboard or by self.master.winfo_toplevel().event_ge

[issue2493] Remove unused constants from optimized code objects

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- assignee: -> rhettinger nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bug

[issue2490] Assertion failure in datetime.strftime()

Pierre Metras <[EMAIL PROTECTED]> added the comment: I did a mistake: OLPC XO is based on Fedora 7 and not 9. They plan to upgrade to 9 later this year (http://wiki.laptop.org/go/Fedora), so this bug will disappear by itself if it's confirmed that test.py runs correctly on Python 2.5.x and Fed

[issue2493] Remove unused constants from optimized code objects

New submission from Alexander Belopolsky <[EMAIL PROTECTED]>: When peephole optimizer folds multiple constants into one, the old constants remain in co_consts. Attached patch removes such unused constants. -- components: Interpreter Core files: compress-consts.diff keywords: patch mes

[issue2402] get rid of warnings in regrtest with -3

Changes by Quentin Gallet-Gilles <[EMAIL PROTECTED]>: -- nosy: +quentin.gallet-gilles __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mai

[issue1561] py3k: test_mailbox fails on Windows

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Another patch, which uses newline='' instead. Tests pass. The patch is much smaller, and old files are more likely to be compatible. OTOH, messages are unicode strings with \r\n. Which one do you prefer? Added file: http://bugs.python

[issue2479] Bytearray and io backport

Quentin Gallet-Gilles <[EMAIL PROTECTED]> added the comment: I've just updated my trunk checkout on Ubuntu and run the regression test suite. All tests OK. -- nosy: +quentin.gallet-gilles __ Tracker <[EMAIL PROTECTED]> _

[issue1561] py3k: test_mailbox fails on Windows

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Three months later, one obvious correction: open all (text) files with the newline='\n' option. - This makes files identical between Unix and Windows version - no more os.linesep A compatibility problem: mailboxes created with python2.

[issue2250] rlcompleter raises Exception on bad input

Lorenz Quack <[EMAIL PROTECTED]> added the comment: I was thinking that the code in question could maybe also raise other exceptions. too bad I´m on vacation and can´t try this out myself. I believe the regular expression also matches something like import rlcompleter rlcompleter.Completer().co

[issue2490] Assertion failure in datetime.strftime()

Georg Brandl <[EMAIL PROTECTED]> added the comment: I cannot reproduce this with test.py with Python 2.5.1 on x86 Linux. -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ __

[issue2457] add --help and -h options to pdb

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Committed in r61931. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue2492] Check implementation of new buffer interface for PyString in 2.6

Christian Heimes <[EMAIL PROTECTED]> added the comment: By the way the code is in svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-bytearray -- nosy: +teoliphant __ Tracker <[EMAIL PROTECTED]> __

[issue2492] Check implementation of new buffer interface for PyString in 2.6

New submission from Christian Heimes <[EMAIL PROTECTED]>: I've only implemented (getbufferproc)string_buffer_getbuffer of the new buffer protocol. Do I have to add "exports" to the PyString struct and add a releasebufferproc, too? -- components: Interpreter Core keywords: 26backport mess

[issue2490] Assertion failure in datetime.strftime()

Pierre Metras <[EMAIL PROTECTED]> added the comment: There is an example of a long strftime pattern in the test.py file attached to that issue. Just change the length of the pattern to see that it works for smaller patterns in Python 2.5. The pattern where it occured in my application is a Pan

[issue2491] io.open() handles errors differently on different platforms

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: With python3.0, os.fdopen() is a simple call to io.open(), which has these missing options. Maybe os.fdopen should be deprecated or removed, and replaced by io.open. Moreover, the comment in os.py is wrong: subprocess does not use fdope

[issue2457] add --help and -h options to pdb

Georg Brandl <[EMAIL PROTECTED]> added the comment: Go ahead and commit. -- resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> __ ___ Pytho

[issue2484] Cosmetic patch for warning "unused variable"

Georg Brandl <[EMAIL PROTECTED]> added the comment: Thanks, fixed in r61927. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2488] Backport sys.maxsize to Python 2.6

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: FWIW, I don't see how backports like this add any value at all. The 2- to-3 tool handles renaming well, but a backport just creates a hodge- podge of aliases making the language harder to learn and harder to grep. -- nosy: +rhettin

[issue2488] Backport sys.maxsize to Python 2.6

Georg Brandl <[EMAIL PROTECTED]> added the comment: What about #1570? -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-l

[issue2483] int and float accept bytes, complex does not

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Agreed - I've been convinced that the right thing to do is reject bytes in int() and float() as well. If we decide we still want to support a fast-path conversion it should be via separate methods (e.g an int.from_ascii class method and an int.