[issue2507] Exception state lives too long in 3.0
Antoine Pitrou [EMAIL PROTECTED] added the comment: No, I don't. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2521] ABC caches should use weak refs
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2521 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2780] Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)
New submission from Tim Pietzcker [EMAIL PROTECTED]: Apologies if this has been reported before; I couldn#T find it on a search but maybe I used the wrong search terms. When I try to run a script that is contained in a directory whose path contains non-ASCII characters (e. g. Umlauts), Python 3.0a4 crashes with the following error message: (Windows cmd console): E:\Eigene Dateien\Klinikum\Qualitätsmanagement\Qualitätsbericht 2007c:\programme\python30\python zaehle_aerzte.py Fatal Python error: no mem for sys.path insertion UnicodeDecodeError: 'utf8' codec can't decode bytes in position 33-35: invalid data This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Moving the script to a directory without Umlauts in the path solves the problem. Best regards, Tim -- components: Windows messages: 66355 nosy: pietzcker severity: normal status: open title: Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows) versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2780 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2779] Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)
Tim Pietzcker [EMAIL PROTECTED] added the comment: Please delete this issue - clicked on Submit too soon. Sorry again. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2779 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller [EMAIL PROTECTED] added the comment: Is there any chance this patch will make it into the latest alpha?? Brad __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Raymond Hettinger [EMAIL PROTECTED] added the comment: set_swap_bodies() is fine as it involves pure C with no possible callbacks. The issue is in its use in the __contains__() check. I'll take a look at it and see what if anything needs to be changed. Am lowering the priority because you really have to be trying to create this behavior. -- priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2781] Tiny patch to _winreg docs
New submission from Tim Golden [EMAIL PROTECTED]: The docs for _winreg refer to RegLoadKey, which is the underlying API. The function is actually exposed as LoadKey. Patch attached. -- assignee: georg.brandl components: Documentation files: _winreg.patch keywords: patch messages: 66359 nosy: georg.brandl, tim.golden severity: normal status: open title: Tiny patch to _winreg docs versions: Python 2.6 Added file: http://bugs.python.org/file10207/_winreg.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2781 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2782] datetime/date strftime() method and time.strftime() inconsistency
New submission from Andrii V. Mishkovskyi [EMAIL PROTECTED]: datetime and date strftime() method does additional check on input format, thus being completely different from time's module time.strftime() method behavior. There are two ways to fix this: 1. Add an explicit note about this behavior (e.g., only 'str' objects are allowed for format strings) in docs (section 5.1.7). 2. Allow 'unicode' objects for format strings (backport time.strftime() from 3.0?). Here is a traceback for a more complete overview: Python 2.6a2+ (trunk:62762, May 6 2008, 14:37:27) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. from datetime import datetime, date import time uformat = u'%Y-%m-%D %H-%M-%S' format = '%Y-%m-%D %H-%M-%S' datetime.today().strftime(uformat) Traceback (most recent call last): File stdin, line 1, in module TypeError: strftime() argument 1 must be str, not unicode datetime.today().strftime(format) '2008-05-05/07/08 17-19-03' time.strftime(uformat) '2008-05-05/07/08 17-19-10' time.strftime(format) '2008-05-05/07/08 17-19-16' date.today() datetime.date(2008, 5, 7) date.today().strftime(format) '2008-05-05/07/08 00-00-00' date.today().strftime(uformat) Traceback (most recent call last): File stdin, line 1, in module TypeError: strftime() argument 1 must be str, not unicode -- components: Library (Lib) messages: 66360 nosy: mishok13 severity: normal status: open title: datetime/date strftime() method and time.strftime() inconsistency type: behavior versions: Python 2.5, Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2782 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Eric Smith [EMAIL PROTECTED] added the comment: I'm not sure Py_EnterRecursiveCall is what I want, because that allows the recursion to happen, but just aborts it when it gets too deep. What I want to achieve is to have the warning not called if it's the warning that's being formatted. I coded this up and couldn't get it to do the right thing. I think a better approach will be to remove % formatting from warnings.py. I think that will remove the need for any checks at all. I'll investigate that. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2779] Python 3.0a4 crashes on script in a path with non-ASCII characters (Windows)
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2779 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2783] ctypes.util.find_library() doesn't find OS X .bundle or .so libraries
New submission from Bill Janssen [EMAIL PROTECTED]: On OS X, dynamically loadable libraries come in several flavors: .bundle (or, often, .so) a standard dynamically loadable module; .dylib, a dynamically loadable module that is also a library that can be linked against like a .a file; .framework, a collection of modules similar to a Python package. find_library() currently looks for .dylib and .framework libraries, but not for .bundle or .so libraries. -- assignee: theller components: Library (Lib) keywords: easy messages: 66362 nosy: janssen, theller priority: normal severity: normal status: open title: ctypes.util.find_library() doesn't find OS X .bundle or .so libraries type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2783 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
Changes by Adam Olsen [EMAIL PROTECTED]: -- nosy: +Rhamphoryncus __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1348 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1856] shutdown (exit) can hang or segfault with daemon threads running
Adam Olsen [EMAIL PROTECTED] added the comment: Cleaned up version of Amaury's patch. I stop releasing the GIL after sys.exitfunc is called, which protects threads from the ensuing teardown. I also grab the import lock (and never release it). This should prevent the nasty issue with daemon threads doing imports mentioned in issue 1720705, so that part of the documentation change can be removed. I didn't do any significant testing though. Importing raises a potential issue with this approach. The standard meme of release GIL; grab lock; acquire GIL becomes invalid. A child may grab the lock, then block on the GIL, while the main thread (which never releases the GIL) will block on acquiring the lock. I worked around it with the import lock due to it's recursive behaviour, but if it exists anywhere else in CPython it may cause a problem if used during shutdown. -- keywords: +patch Added file: http://bugs.python.org/file10208/python-thread_noswap-2.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2302] Uses of SocketServer.BaseServer.shutdown have a race
Rafael Zanella [EMAIL PROTECTED] added the comment: With the code as it stands, calls to shutdown that happen before serve_forever enters its loop will deadlock, and there's no simple way for the user to avoid this. The attached patch prevents the deadlock and allows multiple serve_forever..shutdown cycles, but it's pretty complicated. I could make it a lot simpler by making shutdown permanent: any later serve_forever calls would return immediately. Never thought of using the SocketServer taht way, wouldn't the person doing this bunch of shutdown()s and serve_forever()s be better off using handle_request() on a loop instead ? A third choice would be to add a .serve_in_thread function that returns a token that can be used to shut down exactly that loop, instead of putting .shutdown() on the server. Any opinions? I don't think I understand this part, what loop do you refer to ? -- nosy: +zanella __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, May 7, 2008 at 10:33 AM, Eric Smith [EMAIL PROTECTED] wrote: I think a better approach will be to remove % formatting from warnings.py. I think that will remove the need for any checks at all. I'll investigate that. That would make user code warning that uses '%' brittle. However, if we warn about it, I think it's ok. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Martin v. Löwis [EMAIL PROTECTED] added the comment: Is there any chance this patch will make it into the latest alpha?? I don't think there is any such chance. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller [EMAIL PROTECTED] added the comment: On May 7, 2008, at 1:55 PM, Martin v. Löwis wrote: Thanks for the very clear answer. This being my first attempt at contributing to the Python core, I am looking for some sort of clarity on the future of this patch. It feels like some sort of consensus was reached and now the patch has been lingering without additional comment for several weeks. I have some sense of urgency in knowing the future as the final opportunity to include these changes in my introduction to CS book is looming on the horizon. Thanks, Brad __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2784] fast builtin sum may leak
New submission from Jean Brouwers [EMAIL PROTECTED]: The new, fast builtin sum implementation may cause a memory leak in the float loop. Both lines PyFPE_START_PROTECT(add, return 0) should be changed to PyFPE_START_PROTECT(add, Py_DECREF(item); Py_DECREF(iter); return 0) The attached file bltinmodule1.c.diff contain a patch to that extent. /Jean Brouwers -- components: Interpreter Core files: bltinmodule1.c.diff keywords: patch messages: 66368 nosy: MrJean1 severity: normal status: open title: fast builtin sum may leak type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10209/bltinmodule1.c.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2784 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2785] alternate fast builtin sum
New submission from Jean Brouwers [EMAIL PROTECTED]: The attached patch bltmodule2.c.diff is a different implementation of the fast summation code for your consideration. It uses three separate sums to add ints, floats and other objects. All ints are accumulated into a C long, reset even after overflow. All floats are added into a C double without mixing ints. Other objects are handled as before. This version has been tested with Python 2.5.2 as well and passed the existing regressions. /Jean Brouwers -- components: Interpreter Core files: bltinmodule2.c.diff keywords: patch messages: 66369 nosy: MrJean1 severity: normal status: open title: alternate fast builtin sum type: performance versions: Python 2.6 Added file: http://bugs.python.org/file10210/bltinmodule2.c.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2785 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2722] os.getcwd fails for long path names on linux
Matthias Urlichs [EMAIL PROTECTED] added the comment: MAX_PATH is a compile time constant which, like FD_BITS for select(), may be too small for the system you're ultimately running on. Using that as default initial size is OK, but handling ERANGE is still a very good idea. -- nosy: +smurfix __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2722 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Adam Olsen [EMAIL PROTECTED] added the comment: The intended use is unsafe. contains, remove, and discard all use it for a lookup, which can't be fixed. Upon further inspection, intersection_update is fine. Only a temporary set (not frozenset!) is given junk, which I don't see as a problem. If someone can confirm that contains/remove/discard's usage is an artifact I'll submit a patch that removes it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2726] Autodoc's autoclass directive should include constructor docstring
Abhik Shah [EMAIL PROTECTED] added the comment: Works great.. Thanks! On Sun, May 4, 2008 at 5:38 AM, Georg Brandl [EMAIL PROTECTED] wrote: Georg Brandl [EMAIL PROTECTED] added the comment: Okay, I added a config value (autoclass_content) in r62697. Let me know what you think! -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2726 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2726 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in traceback should have class names, if they're methods
New submission from Matthias Urlichs [EMAIL PROTECTED]: Consider this simple error: class foo(object): ... def __init__(self,bar): ...pass ... foo() Traceback (most recent call last): File stdin, line 1, in module TypeError: __init__() takes exactly 2 positional arguments (1 given) The problem is that if that foo call is through a variable (or anything else that obscures which class I'm actually calling) there's no good way to figure this from the traceback. The last line should read TypeError: foo.__init__() takes exactly 2 positional arguments (1 given) or similar. -- messages: 66373 nosy: smurfix severity: normal status: open title: Names in traceback should have class names, if they're methods type: behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2786 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2784] fast builtin sum may leak
Jean Brouwers [EMAIL PROTECTED] added the comment: There is one other, similar issue in the Modules/imgfile.c file. Line 327 is PyFPE_START_PROTECT(readscaled, return 0) and should probably be PyFPE_START_PROTECT(readscaled, iclose(image); return 0) /Jean Brouwers __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2784 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2787] Patch to flush unittest output
New submission from Adam Olsen [EMAIL PROTECTED]: In 3.0, unittest's output has become line buffered. Instead of printing the test name when it starts a test, then ok when it finishes, the test name is delayed until the ok is printed. This makes it unnecessarily hard to determine which test is hanging or segfaulted. The attached patch adds explicit flushes. An alternative approach would be to force stdout to be unbuffered somehow. I don't know how difficult that would be. -- files: python-unittest_flush.diff keywords: patch messages: 66375 nosy: Rhamphoryncus severity: normal status: open title: Patch to flush unittest output versions: Python 3.0 Added file: http://bugs.python.org/file10211/python-unittest_flush.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2787 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2787] Patch to flush unittest output
Adam Olsen [EMAIL PROTECTED] added the comment: Hrm, this behaviour exists in trunk as well. I must be confused about the cause (but the patch still fixes it.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2787 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2788] ignore file for Mercurial
New submission from Antoine Pitrou [EMAIL PROTECTED]: Here is an .hgignore file to put in the base directory of both the trunk and the py3k branch. -- components: Build files: .hgignore messages: 66377 nosy: pitrou severity: normal status: open title: ignore file for Mercurial versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10212/.hgignore __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2788 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2785] alternate fast builtin sum
Antoine Pitrou [EMAIL PROTECTED] added the comment: What is the benefit of this new implementation? If it is faster, can you give us any performance numbers? (for example using timeit) -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2785 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2507] Exception state lives too long in 3.0
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a last patch fixing without lines longer than 78 chars. Added file: http://bugs.python.org/file10213/exc_cleanup4.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Christian Heimes [EMAIL PROTECTED] added the comment: Command to merge json into 3.0: svnmerge.py unblock -r62734,62736,62748,62769; svnmerge.py merge --force -r62734,62736,62748,62769 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, May 7, 2008 at 7:08 PM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] added the comment: Command to merge json into 3.0: svnmerge.py unblock -r62734,62736,62748,62769; svnmerge.py merge --force -r62734,62736,62748,62769 Why is the --force needed? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2785] alternate fast builtin sum
Jean Brouwers [EMAIL PROTECTED] added the comment: I did not compare performance (yet). If there is a particular test case, I am happy to measure that. Also, I made sure that the results and errors (!) for non-numeric items are the same as for the original, Slow Summation case. The version I submitted is perhaps only slightly faster for most int and float cases, since it never creates and adds the 0 int default for the optional 'start' argument. For other int and float cases it will certainly be faster. Here are a few (extreme) examples. 1) Assume a long list consisting of one float followed by all ints. The existing code will switch to the float loop at the very first float encountered and then use C double add (plus the FPE protection overhead) to add all subsequent ints. My version will use C long adds for all ints, C double add for the float plus one C double add to combine the long and double results. 2) Consider a list of just 2 items, one float and one int (and no 'start' argument). The current code will first create a result object for the 'start' default 0. Then, it enters the int loop (since result is an int, 0) and gets the first item, the float. Since the item is not an int, it is added to the current result using PyNumber_Add. Next, it falls into the float loop, since the result is now a float, presumably. Next, it gets the int item and adds that int as C double to the C double in f_result. The end result C double f_result is returned as float. Quite costly for just one float and one int and maybe worse than than Slow Summation. 3) My version does not create a 0 int for the missing 'start'. That is only created when absolutely needed at some later time. In addition, all int items are added in C long i_sum and all floats are added in C double f_sum, regardless of the order they occur in the sequence. At the end of the iteration loop, the C long i_sum is added to C double f_sum once and a single float object is created and returned. That is very efficient and without any unnecessary overhead. In other words, for sequences with mixed int and float objects the difference can be significant, depending on where the very first float item is located in the sequence and how may int follow. However, for sequences with items of the same type, all int or all float, there will be little or no difference. /Jean Brouwers PS) There are two additional things to consider for the float case: - Ooverflow (ERANGE) and value (EDOM) errors in C double adds - Using a compensating summation for floats, like Kahan's method. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2785 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Christian Heimes [EMAIL PROTECTED] added the comment: Because I haven't committed the result of svnmerge.py unblock yet. svnmerge.py refuses to work on a sandbox with uncommitted changes. 2to3: ./python Tools/scripts/2to3 -w Lib/json/ ./python Tools/scripts/2to3 -w -d Lib/json/ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Eric Smith [EMAIL PROTECTED] added the comment: That would make user code warning that uses '%' brittle. However, if we warn about it, I think it's ok. True enough. Then I think we should go with: 1. Use .format() in the warnings module. 2. Tell the users not to use % formatting in user code for warnings. 3. Add my original, simple, global check for recursion. It will work incorrectly in an insignificant number of cases, and will typically result in at least one warning about % formatting, anyway. I'll have a patch ready soon. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Christian Heimes [EMAIL PROTECTED] added the comment: I got the JSON module working under Python 3.0. I'm still not happy with the mixing of bytes and unicode, though. The patch contains additional changes to svnmerge.py unblock -r62734,62736,62748,62769; svnmerge.py merge --force -r62734,62736,62748,62769 Added file: http://bugs.python.org/file10214/json_py3k.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Rafael Zanella [EMAIL PROTECTED] added the comment: AFAIK the lookup on dictionaries is faster than on lists. Patch added, mainly a compilation of the previous patches with an expanded test. -- nosy: +zanella Added file: http://bugs.python.org/file10215/re_patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2785] alternate fast builtin sum
Jean Brouwers [EMAIL PROTECTED] added the comment: Here is one, simple comparison between 3 different builtin_sum's, all measured on the same machine, MacOS X 10.4.11 (Intel Duo): 1) Python 2.5.1 ActiveState with standard Slow Summation: % python2.5.1 -mtimeit --setup=x=[1.0e12, 7]*100 sum(x) 10 loops, best of 3: 177 msec per loop 2) Python 2.6a2 (built from source) with the existing Fast Summation: % python2.6a2 -mtimeit --setup=x=[1.0e12, 7]*100 sum(x) 10 loops, best of 3: 52.5 msec per loop 3) Python 2.5.2 (built from source) with the submitted Fast Summation: % python2.5.2 -mtimeit --setup=x=[1.0e12, 7]*100 sum(x) 10 loops, best of 3: 48.2 msec per loop __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2785 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346238] A constant folding optimization pass for the AST
Thomas Lee [EMAIL PROTECTED] added the comment: I'm working on the AST optimization code for 2.7 (?) in the tlee-ast-optimize branch. I've since adopted some of the ideas from this patch, but I'll take another look when I get a chance. The folding operation is already mostly in-place. -- nosy: +thomas.lee _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1346238 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2785] alternate fast builtin sum
Raymond Hettinger [EMAIL PROTECTED] added the comment: Will take a look at this one but am inclined to reject it. The timing benefits are marginal at best and only help in the atypical case of mixed floats and ints. The patch changes the type and ordering of intermediate sums, resulting in different answers than the standard sum (). In contrast, the existing fast sum() was carefully designed to mimick the operations of the original sum(), so it always produces the same results. -- assignee: - rhettinger nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2785 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2784] fast builtin sum may leak
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2784 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a pure Python patch removing the quadratic behaviour and trying to make read operations generally faster. Here are some numbers: ./python -m timeit -s f = open('50KB', 'rb') f.seek(0) while f.read(11): pass - py3k without patch: 23.6 msec per loop - py3k with patch: 14.5 msec per loop - Python 2.5: 4.72 msec per loop ./python -m timeit -s f = open('50KB', 'rb') f.seek(0); f.read() - py3k without patch: 284 usec per loop - py3k with patch: 90.1 usec per loop - Python 2.5: 33.8 usec per loop ./python -m timeit -s f = open('100KB', 'rb') f.seek(0); f.read() - py3k without patch: 828 usec per loop - py3k with patch: 142 usec per loop - Python 2.5: 62.5 usec per loop ./python -m timeit -s f = open('200KB', 'rb') f.seek(0); f.read() - py3k without patch: 3.67 msec per loop - py3k with patch: 375 usec per loop - Python 2.5: 131 usec per loop And, for the record, with a 10MB file: ./python -m timeit -s f = open('10MB', 'rb') f.seek(0); f.read() - py3k without patch: still running after more than one minute, gave up - py3k with patch: 38.6 msec per loop - Python 2.5: 20.4 msec per loop -- keywords: +patch Added file: http://bugs.python.org/file10216/binaryio1.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Benjamin Peterson [EMAIL PROTECTED] added the comment: When you've merged it, I'll alter the 3.0 docs. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2717] tempfile.mkstempf
Skip Montanaro [EMAIL PROTECTED] added the comment: The conclusion on python-dev is that NamedTemporaryFile is an adequate replacement for mktemp, so this isn't needed. -- resolution: - rejected status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2717 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: I see that the code is still using the immutable bytes object for its buffer (which forces Python to create a new buffer every time its modified). Also, I think it worthwhile to check if using a pre-allocated bytearray object (i.e., bytearray(buffer_size) where `buffer_size` is an integer) would have any performance benefits. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Barry A. Warsaw [EMAIL PROTECTED] added the comment: This is not a release blocker for 2.6 or 3.0. -- nosy: +barry priority: release blocker - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Adam Olsen [EMAIL PROTECTED] added the comment: I decided not to wait. Here's a patch. Several of set's unit tests covered the auto-conversion, so I've modified them. -- keywords: +patch Added file: http://bugs.python.org/file10217/python-setswap.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Antoine Pitrou [EMAIL PROTECTED] added the comment: Hi Alexandre, I first tried to use a (non-preallocated) bytearray object and, after trying several optimization schemes, I found out that the best one worked as well with an immutable bytes object :) I also found out that the bytes - bytearray conversion costs can be noticeable in some benchmarks. The internal buffer is rarely reallocated because the current offset inside it is remembered instead; also, when reading bytes from the underlying unbuffered stream, a list of bytes objects is accumulated and then joined at the end. I think a preallocated bytearray would not make a lot of sense since we can't readinto() an arbitrary position, so we still have a memory copy from the bytes object returned by raw.read() to the bytearray buffer, and then when returning the result to the user as a bytes object we have another memory copy. In other words each read byte is copied twice more. Of course, if this code was rewritten in C, different compromises would be possible. cheers Antoine. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2788] ignore file for Mercurial
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: I have a slightly different .hgignore for my personal mercurial branch. Although, I don't really like the idea of polluting the main subversion repository with the ignore files of other VCS. -- nosy: +alexandre.vassalotti Added file: http://bugs.python.org/file10218/hgignore.txt __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2788 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2548] Undetected error in exception handling
Barry A. Warsaw [EMAIL PROTECTED] added the comment: I'm not going to hold up the 2.6 alpha release for this, but will bump it up for the first 2.6 beta. -- nosy: +barry priority: release blocker - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2548 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Barry A. Warsaw [EMAIL PROTECTED] added the comment: Guido, can you comment on Amaury's latest patch? I'm going to bump this back to critical so as not to hold up 2.6 alpha, but it should be marked as a release blocker for the first beta. -- nosy: +barry priority: release blocker - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Barry A. Warsaw [EMAIL PROTECTED] added the comment: Bumping this down to critical for the alpha release. It should be release blocker for the first beta. -- nosy: +barry priority: release blocker - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Raymond Hettinger [EMAIL PROTECTED] added the comment: Rejecting this patch which simply disables a feature that some users consider to be important. I will look at it further. Right now, I'm inclined to simply document that the three temporary autoconversions deny meaningful contemporaneous access to a set used as a key. The set_swap_bodies() function itself is fine -- it behaves just like an atomic version of the pure python sequence: t=set(a); a.clear(); a.update(b); b.clear(); b.update(t); del t. The issue is simply that the swap/search/swap dance allows the possibility that a determined user could graft onto the search step and access but not modify the temporary swapped-in frozenset. It doesn't crash; it simply produces an undefined result. I'm not losing sleep over this scenario. I'm am entertaining an alternative where contains/discard/remove would duplicate instead of swap the set bodies; however, that approach may do more harm than good. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2789] Comparsion datetime objects with None
New submission from Alexandr Zamaraev [EMAIL PROTECTED]: When comparing any standard objects with None returned True or False. When comparing the object of the module datetime with None raised exception TypeError. Example Python session: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import datetime as dt import decimal as dc None == 1 False None == s False None == [1, 2, 3] False None == (1, 2, 3) False None == dc.Decimal() False None == dt.date.today() False None == dt.datetime.today() False None == dt.time() False None == dt.timedelta() False None 1 True None s True None [1, 2, 3] True None (1, 2, 3) True None dc.Decimal() True None dt.date.today() Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare datetime.date to NoneType None dt.datetime.today() Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare datetime.datetime to NoneType None dt.time() Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare datetime.time to NoneType None dt.timedelta() Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare datetime.timedelta to NoneType -- components: Library (Lib) files: datetimemodule.diff keywords: patch messages: 66402 nosy: shura_zam severity: normal status: open title: Comparsion datetime objects with None versions: Python 2.5 Added file: http://bugs.python.org/file10219/datetimemodule.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2532] file that breaks 2to3 (despite being correct python)
Changes by Rodrigo Bernardo Pimentel [EMAIL PROTECTED]: -- nosy: +rbp __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2532 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2222] Memory leak in os.rename?
Changes by Neal Norwitz [EMAIL PROTECTED]: -- priority: normal - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2507] Exception state lives too long in 3.0
Barry A. Warsaw [EMAIL PROTECTED] added the comment: r62847 -- priority: release blocker - critical resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Adam Olsen [EMAIL PROTECTED] added the comment: PEP 218 explicitly dropped auto-conversion as a feature. Why should this be an exception? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Ismail Donmez [EMAIL PROTECTED] added the comment: This _must_ be a release blocker for Python 3.0, Its a shame that this bug still is not fixed and a patch is available for months now. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Raymond Hettinger [EMAIL PROTECTED] added the comment: If needed, I'll update the PEP to be more clear. The sets.py module had two protocols: __as_immutable__() and __as_temporarily_immutable__ (). The first protocol was the one that was dropped -- it triggered with something like s1.add(s2) and it automatically created a frozenset copy of s2. The second protocol is used in contains/remove/discard. Alex Martelli successfully lobbied for its retention. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Guido van Rossum [EMAIL PROTECTED] added the comment: imageop is deleted in 3.0. See PEP 3108. So it can't be a release blocker. This also explains my general lack of interest in this module. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Ismail Donmez [EMAIL PROTECTED] added the comment: I am sorry for the drama then, :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com