[issue3473] In function call, keyword arguments could follow *args
Raymond Hettinger [EMAIL PROTECTED] added the comment: +1 for applying to 2.6. izip_longest() is a perfect example of where it's important. -- nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3474] Using functools.reduce() does not stop DeprecationWarning when using -3
Raymond Hettinger [EMAIL PROTECTED] added the comment: Can't this be handled by 2-to-3 instead of a -3 warning? -- components: +2to3 (2.x to 3.0 conversion tool) -Library (Lib) nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3469] Umlauts make conf.latex_documents fail
Berthold Höllmann [EMAIL PROTECTED] added the comment: OK, using Unicode strings in conf.py does work, so make this a Bug in sphinx-quickstart. My conf.py was generated by sphinx-quickstart, When asked for the author(s) name I gave my name and conf.py was generated with a simple string for the name information instead of a Unicode string. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3475] _elementtree.c import can fail silently
New submission from Matteo Bertini [EMAIL PROTECTED]: Playing with PyInstaller I have found that the final part of _elementtree.c: Index: Modules/_elementtree.c === --- Modules/_elementtree.c (revisione 59540) +++ Modules/_elementtree.c (copia locale) @@ -2780,7 +2780,10 @@ ); -PyRun_String(bootstrap, Py_file_input, g, NULL); +if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL) +return; elementpath_obj = PyDict_GetItemString(g, ElementPath); execute a bit of python code without checking the return value. That can lead to weird things playing with import hooks, for example an assert like this can fail: Index: Lib/test/test_elemettree.py === --- Lib/test/test_elemettree.py (revisione 0) +++ Lib/test/test_elemettree.py (revisione 0) @@ -0,0 +1,21 @@ +#! /usr/bin/env python + +def importHook(*args, **kwargs): +if 'xml.etree' in args: +raise ImportError +else: +return __real__import__(*args, **kwargs) + +import os +import __builtin__ +__real__import__ = __builtin__.__import__ +__builtin__.__import__ = importHook + +try: +import xml.etree.cElementTree as cET +except ImportError: +pass +else: +out = os.popen(python -c 'import xml.etree.cElementTree as cET; print dir(cET)').read().strip() +assert str(dir(cET)) == out, (str(dir(cET)), out) + -- components: XML messages: 70488 nosy: naufraghi severity: normal status: open title: _elementtree.c import can fail silently versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3475] _elementtree.c import can fail silently
Martin v. Löwis [EMAIL PROTECTED] added the comment: Fredrik, can you take a look? -- assignee: - effbot nosy: +effbot, loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1878] class attribute cache failure (regression)
Raymond Hettinger [EMAIL PROTECTED] added the comment: Guido, what say you, live with it, revert it, or apply Py_TPFLAGS_HAVE_VERSION_TAG to all core types? -- assignee: arigo - gvanrossum nosy: +gvanrossum, rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2389] Array pickling exposes internal memory representation of elements
Raymond Hettinger [EMAIL PROTECTED] added the comment: At this point, I think it better to wait until Py2.7/3.1. Changing it now would just complicate efforts to port from 2.5 to 2.6 to 3.0. Guido, do you agree? -- assignee: - gvanrossum nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2965] Update interface of weakref dictionaries
Antoine Pitrou [EMAIL PROTECTED] added the comment: Is it ok that the keys/values/items return iterators rather than views? -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2965] Update interface of weakref dictionaries
Antoine Pitrou [EMAIL PROTECTED] added the comment: By the way, code like: items1 = list(dict.items()) items1.sort() could be simplified into: items1 = sorted(dict.items()) (same for reversed() instead of list.reverse()) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
New submission from Antoine Pitrou [EMAIL PROTECTED]: As discovered in #3139, io.BufferedWriter mutates the size of its internal bytearray object. Consequently, invocations of write() from multiple threads can produce exceptions when one thread gets a buffer to the bytearray while the other thread tries to resize it. This especially affects calling print() from multiple threads. A solution is to use a fixed-size (preallocated) bytearray object. Another solution is to get rid of the bytearray approach and replace it with a growing list of immutable bytes objects. Here is the test script provided by Amaury: import sys, io, threading stdout2 = io.open(sys.stdout.fileno(), mode=w) def f(i): for i in range(10): stdout2.write(unicode((x, i)) + '\n') for x in range(10): t = threading.Thread(target=f, args=(x,)) t.start() (with py3k, replace stdout2.write with a simple print) -- components: Library (Lib) messages: 70494 nosy: amaury.forgeotdarc, pitrou priority: high severity: normal status: open title: BufferedWriter not thread-safe type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Martin, sorry for noticing this now but on python-dev you had proposed the following: « I propose that new codes s*, t*, w* are added, and that s#,t#,w# refuses objects which implement a releasebuffer procedure (alternatively, s# etc might be removed altogether right away) » I don't see any changes to s# and t# in your patch. Do you plan to do it later or do you think this part should be dropped? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Giampaolo Rodola' [EMAIL PROTECTED] added the comment: Now that the major bugs have been fixed I think this patch needs to be re-adapted to the new asynchat.py currently available in the trunk. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: OK after a long discussion on the mailing list, Guido gave this the OK, with the provision that there are str-bytes and bytes-str versions of these functions as well. So I've written those. http://mail.python.org/pipermail/python-dev/2008-July/081601.html quote itself now accepts either a str or a bytes. quote_from_bytes is a new function which is just an alias for quote. (Is this acceptable?) unquote is still str-str. I've added a totally separate function unquote_to_bytes which is str-bytes. Note there is a slight issue here: I didn't quite know what to do with unescaped non-ASCII characters in the input to unquote_to_bytes - they need to somehow be converted to bytes. I chose to encode them using UTF-8, on the basis that they technically shouldn't be in a URI anyway. Note that my new unquote doesn't have this problem; it's carefully written to preserve the Unicode characters, even if they aren't expressible in the given encoding (which explains some of the code bloat). This makes unquote(s, encoding=e) necessarily more robust than unquote_to_bytes(s).decode(e) in terms of unescaped non-ASCII characters in the input. I've also added new test cases and documentation for these two new functions (included in patch6). On an entirely personal note, can whoever checks this in please mention my name in the commit log - I've put in at least 30 hours researching and writing this patch, and I'd like for this not to go uncredited :) Commit log for patch6: Fix for issue 3300. urllib.parse.unquote: Added encoding and errors optional arguments, allowing the caller to determine the decoding of percent-encoded octets. As per RFC 3986, default is utf-8 (previously implicitly decoded as ISO-8859-1). urllib.parse.quote: Added encoding and errors optional arguments, allowing the caller to determine the encoding of non-ASCII characters before being percent-encoded. Default is utf-8 (previously characters in range(128, 256) were encoded as ISO-8859-1, and characters above that as UTF-8). Also characters/bytes above 128 are no longer allowed to be safe. Also now allows either bytes or strings. Added functions urllib.parse.quote_from_bytes, urllib.parse.unquote_to_bytes. Doc/library/urllib.parse.rst: Updated docs on quote and unquote to reflect new interface, added quote_from_bytes and unquote_to_bytes. Lib/test/test_urllib.py: Added several new test cases testing encoding and decoding Unicode strings with various encodings, as well as testing the new functions. Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py, Lib/test/test_wsgiref.py: Updated and added test cases to deal with UTF-8-encoded URIs. Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote with encoding=latin-1, to preserve existing behaviour (which the whole email module is dependent upon). Added file: http://bugs.python.org/file11009/parse.py.patch6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3477] grammar productionlist are not properly indented
New submission from Amaury Forgeot d'Arc [EMAIL PROTECTED]: See http://docs.python.org/dev/reference/expressions.html#id9 the production rule for argument_list is not properly indented. It seems that the first line is indented up to the widest name of the list, but subsequent lines only add 6 to the length of the defined name. -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70498 nosy: amaury.forgeotdarc, georg.brandl severity: normal status: open title: grammar productionlist are not properly indented versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3473] In function call, keyword arguments could follow *args
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- keywords: +patch Added file: http://bugs.python.org/file11010/kwargs30.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3473] In function call, keyword arguments could follow *args
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Patches for both versions are attached. Added file: http://bugs.python.org/file11011/kwargs26.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Daniel Arbuckle [EMAIL PROTECTED] added the comment: I'll update the patch and post it again. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Nick Coghlan [EMAIL PROTECTED] added the comment: I personally like the idea of making fieldnames a property - while having merely reading an attribute cause disk I/O is slightly questionable, it seems like a better option than returning a misleading value for that property and also a better option than reading the first line of the file in __init__. Hopefully Skip can track down that obscure failure and this change can be made at some point in the future. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3473] In function call, keyword arguments could follow *args
Benjamin Peterson [EMAIL PROTECTED] added the comment: The patches look good to me. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a sample implementation (using a fixed-size bytearray) with test. Amaury, would you like to take a look? I'm a bit puzzled by the shady BufferedRandom semantics: though the tests do pass, it's hard to say why e.g. BufferedRandom.tell() was implemented like that. -- keywords: +patch Added file: http://bugs.python.org/file11012/bufferedwriter.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Benjamin Peterson [EMAIL PROTECTED] added the comment: It seems that as with the quadratic binary buffered reading, the best solution is the list of bytes which should be especially helped by your bytes joining optimization. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't see any changes to s# and t# in your patch. Do you plan to do it later or do you think this part should be dropped? It's implemented. When bf_releasebuffer is not NULL, convertbuffer will complain string or read-only buffer. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3478] Documentation for struct module is out of date in 3.0
New submission from Matt Giuca [EMAIL PROTECTED]: The documentation for the struct module still uses the term string even though the struct module itself deals entirely in bytes objects in Python 3.0. I propose updating the documentation to reflect the 3.0 terminology. I've attached a patch for the Docs/library/struct.rst file. It mostly renames string to bytes. It also notes that pack for 'c', 's' and 'p' accepts either string or bytes, but unpack spits out a bytes. One important point: If you pass a str to 'c', 's' or 'p', it will get encoded with UTF-8 before being packed. I've described this behaviour in the documentation. I'm not sure if this should be described as the official behaviour, or just informatively. I've traced this behaviour to Modules/_struct.c lines 607, 1650 and 1676 (for 'c', 's' and 'p' respectively), which calls _PyUnicode_AsDefaultEncodedString. This is found in Object/unicodeobject.c:1410, which directly calls PyUnicode_EncodeUTF8. Hence the UTF-8 encoding is not system or locale specific - it will always happen. However, perhaps we should loosen the documentation to say which are encoded using a default encoding scheme. It would be good if the authors of the struct module read over these changes first, to make sure I am describing it correctly. I have also updated Modules/_struct.c's doc strings and exception messages to reflect this new terminology. (I've changed nothing besides the contents of these strings - test case passes, just to be safe). Patch is for /python/branches/py3k/, revision 65324. Commit Log: Docs/library/struct.rst: Updated documentation to Python 3.0 terminology (bytes instead of strings). Added note that packing 'c', 's' or 'p' accepts either str or bytes. Modules/_struct.c: Updated doc strings and exception messages to the same. -- assignee: georg.brandl components: Documentation files: struct-doc.patch keywords: patch messages: 70506 nosy: georg.brandl, mgiuca severity: normal status: open title: Documentation for struct module is out of date in 3.0 versions: Python 3.0 Added file: http://bugs.python.org/file11013/struct-doc.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3424] imghdr test order makes it slow
Benjamin Peterson [EMAIL PROTECTED] added the comment: Ok. Would you like to propose an alternate order? -- status: pending - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3424 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2819] Full precision summation
Mark Dickinson [EMAIL PROTECTED] added the comment: [Tim] if you're concerned about speed, it would probably pay to eliminate all library calls except one to frexp(). Indeed it would! Here's a revised patch that avoids use of fmod. Speed is comparable with the current version. Here are some timings for summing random values on OS X/Core 2 Duo, on a non-debug build of the trunk. lsum is the patched version, msum is the version in the current trunk; timings are in seconds. | lsum| msum +--+- 5 random values in [0, 1) | 0.003091 | 0.002540 5 random values in [0, 1), sorted | 0.003202 | 0.003043 5 random values in [0, 1), reverse order| 0.003201 | 0.002587 5 random values in [-1, 1) | 0.003229 | 0.002829 5 random values in [-1, 1), sorted | 0.003183 | 0.002629 5 random values in [-1, 1), reverse order | 0.003195 | 0.002731 5 random exponential values | 0.003994 | 0.006178 5 random exponential values, sorted | 0.003713 | 0.007933 5 random exponential values, reverse order | 0.003714 | 0.002849 Note that lsum doesn't suffer from the 'fragmentation of partials' problem that slows down msum for sorted datasets. I'll do some timings on Linux/x86 as well. Added file: http://bugs.python.org/file11014/fsum10.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon Benjamin Peterson [EMAIL PROTECTED]: Benjamin Peterson [EMAIL PROTECTED] added the comment: It seems that as with the quadratic binary buffered reading, the best solution is the list of bytes which should be especially helped by your bytes joining optimization. I don't really know. The logic is quite different (and harder to get right) than in BufferedReader. I might try to write a list-of-bytes version and do some timings, but it's not trivial... I should first compare against the current version. Also, an advantage of using a fixed-size bytearray is that it more closely mimicks what will have to be written for an efficient C implementation. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3473] In function call, keyword arguments could follow *args
Nick Coghlan [EMAIL PROTECTED] added the comment: I'll have a look at this in the next day or two. -- nosy: +ncoghlan ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Thu, Jul 31, 2008 at 9:36 AM, Antoine Pitrou [EMAIL PROTECTED] wrote: I don't really know. The logic is quite different (and harder to get right) than in BufferedReader. I might try to write a list-of-bytes version and do some timings, but it's not trivial... I should first compare against the current version. Also, an advantage of using a fixed-size bytearray is that it more closely mimicks what will have to be written for an efficient C implementation. You are correct that this should probably be rewritten in C at some point, so let's go with this. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Hmm ... seems patch 6 I just checked in fails a test case! Sorry! (It's minor, gives a harmless BytesWarning if you run with -b, which make test does, so I only picked it up after submitting). I've slightly changed the code in quote so it doesn't do that any more (it normalises all safe arguments to bytes). Please review patch 7, not 6. Same commit log as above. (Also .. someone let me know if I'm not submitting patches properly, like perhaps I should be deleting the old ones not keeping them around?) Added file: http://bugs.python.org/file11015/parse.py.patch7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3478] Documentation for struct module is out of date in 3.0
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for the patch! Done in r65327. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Ok for s#. But t# uses bf_getcharbuffer(), which does not seem to lock anything. I wonder if this can lead to the same kind of problems, for example when calling file_write with a binary file. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3478] Documentation for struct module is out of date in 3.0
Matt Giuca [EMAIL PROTECTED] added the comment: Thanks for the props! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2902] tkinter uses MacOS
Guilherme Polo [EMAIL PROTECTED] added the comment: as I understand, MacOS.SchedParams is gone for more than 4 years now (that is why you see this hasattr check everywhere). I doubt removing this MacOS usage will do anything. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11016/issue3436.py3k.csv.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11017/issue3436.trunk.csv.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2902] tkinter uses MacOS
Benjamin Peterson [EMAIL PROTECTED] added the comment: Great! It's gone in r65328. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3479] unichr integer overflow
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Confirmed. This happens on architectures where sizeof(long) sizeof(int): builtin_unichr() converts its argument to a long, but calls PyUnicode_FromOrdinal() which accepts an int. -- assignee: - amaury.forgeotdarc nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Bill Janssen [EMAIL PROTECTED] added the comment: Thanks. I'll read it. Bill On Thu, Jul 31, 2008 at 6:16 AM, Daniel Arbuckle [EMAIL PROTECTED]wrote: Daniel Arbuckle [EMAIL PROTECTED] added the comment: I'll update the patch and post it again. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ Added file: http://bugs.python.org/file11018/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___div dir=ltrThanks.nbsp; I#39;ll read it.brbrBillbrbrdiv class=gmail_quoteOn Thu, Jul 31, 2008 at 6:16 AM, Daniel Arbuckle span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/span wrote:br blockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;br Daniel Arbuckle lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br I#39;ll update the patch and post it again.br divdiv/divdiv class=Wj3C7cbr ___br Python tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue1563; target=_blankhttp://bugs.python.org/issue1563/agt;br ___br /div/div/blockquote/divbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Andrii V. Mishkovskyi [EMAIL PROTECTED] added the comment: I like the idea of fieldnames attribute being a property, so i've uploaded patches that implement them as such. Both patches ran through make test without problems. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2819] Full precision summation
Mark Dickinson [EMAIL PROTECTED] added the comment: Timings on x86/Linux are similar: the lsum-based version is around 10% slower on average, 25% slower in the worst case, and significantly faster for the msum worst cases. There's probably still some snot left to optimize out, though. Some tempting ideas are: (1) to try using doubles instead of longs for the accumulator digits (with 51 or 52 bits of precision), and (2) to split each mantissa into (nearest_integer, fraction) instead of (next_smallest_integer, fraction), using rint or lrint. Anything else? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1878] class attribute cache failure (regression)
Armin Rigo [EMAIL PROTECTED] added the comment:
Maybe there is a better solution along the following line: conditionally
define Py_TPFLAGS_DEFAULT so that when compiling the Python core it
includes the Py_TPFLAGS_HAVE_VERSION_TAG, but when compiling extension
modules it does not. This should ensure compatibility with many
existing extension modules. (It would still break if they play tricks
like modifying the tp_dict of types other than their own.)
In addition, to support the method cache in newer C extension modules:
* C types defined by C extension modules can include the
Py_TPFLAGS_HAVE_VERSION_TAG explicitly to enable the cache;
* new C API functions should be introduced to give an official way to
access the tp_dict of a type, e.g. PyType_{Get,Set,Del}DictItemString().
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich [EMAIL PROTECTED] added the comment: Thanks for the ping. I just rewrote the patch from scratch and it handles corner cases (of which there are many in the parse tree) better. I'll upload/checkin sometime today. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length
Guido van Rossum [EMAIL PROTECTED] added the comment: On the issue of whether len(range()) should be allowed to be sys.maxsize, I think this should be allowed. I think in the future we should change the __len__ protocol to allow unbounded lengths. Even today, I think range(10**100).__len__() should return 10**100 rather than raising an OverflowError, even if len(range(10**100)) raises OverflowError. I also think ranges should be introspectable, exposing their start, stop and step values just like slice objects. Probably all those changes are for post 3.0. -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3474] Using functools.reduce() does not stop DeprecationWarning when using -3
Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Jul 30, 2008 at 11:32 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Raymond Hettinger [EMAIL PROTECTED] added the comment: Can't this be handled by 2-to-3 instead of a -3 warning? Well, there is the problem of someone having a function already named reduce() and the import. Since 2to3 can't go back and add an import, every found use of reduce() would need to have an import inserted somewhere. That won't work if reduce() is being used in a expression context instead of a statement context, etc. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3474] Using functools.reduce() does not stop DeprecationWarning when using -3
Benjamin Peterson [EMAIL PROTECTED] added the comment: Alternatively, you could move reduce to functools and have the builtin module issue a warning and call it. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3480] Fix_imports pattern optimization
New submission from Nick Edds [EMAIL PROTECTED]: Here is a substantial improvement to the pattern for fix_imports. It significantly reduces the size of the previous pattern and represents it in a more reasonable way. It still passes all of the tests and it also makes 2to3 roughly two to three times as fast based on the results of some basic testing. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: fix_imports_pattern.diff keywords: patch messages: 70528 nosy: collinwinter, nedds severity: normal status: open title: Fix_imports pattern optimization type: performance Added file: http://bugs.python.org/file11019/fix_imports_pattern.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: But t# uses bf_getcharbuffer(), which does not seem to lock anything. Indeed. I think we can safely drop support for passing buffer objects into t# which have getbuffer/releasebuffer, so the check for releasebuffer being NULL should be added to t#. I think the bytearray object should refuse to implement getcharbuffer, anyway. I wonder if this can lead to the same kind of problems, for example when calling file_write with a binary file. It should be a text file to cause problems, right? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich [EMAIL PROTECTED] added the comment: The new patch works and handles all the corner cases I could think of. I tried to comment the heck out of it because it does a lot of manual walking and manipulation of the syntax tree. This only handles __metaclass__ inside classes. I wasn't sure what to do with __metaclass__ at the module level (which is now a NOP, I think). Added file: http://bugs.python.org/file11020/fix_metaclass.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3479] unichr integer overflow
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed r65339. Will not backport to 2.5: code that used to (approximately) work would break. Thanks for the report! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Skip Montanaro [EMAIL PROTECTED] added the comment:
Nick,
Working with Andrii's patch I'm trying to add a couple test cases to
make sure the methods you and I both demonstrated still work. Mine is
no problem, but I must be doing something wrong trying to use/adapt your
example. I freely admit I am not an itertools user, but I can't get
your example to work as written:
r = csv.DictReader(open(foo.csv, rb))
r.fieldnames
['f1', 'f2', 'f3']
r.next()
{'f1': '1', 'f2': '2', 'f3': 'abc'}
r = csv.DictReader(open(foo.csv, rb))
first = next(r)
first
{'f1': '1', 'f2': '2', 'f3': 'abc'}
import itertools
for x in itertools.chain(first, r):
... print x
...
f1
f2
f3
If I place first in a list it works:
r = csv.DictReader(open(foo.csv, rb))
first = next(r)
for x in itertools.chain([first], r):
... print x
...
{'f1': '1', 'f2': '2', 'f3': 'abc'}
That makes intuitive sense to me. Is that what you intended?
S
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3436
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3474] Using functools.reduce() does not stop DeprecationWarning when using -3
Brett Cannon [EMAIL PROTECTED] added the comment: On Thu, Jul 31, 2008 at 11:56 AM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: Alternatively, you could move reduce to functools and have the builtin module issue a warning and call it. That's what 3.0 did; created _functools and that holds the original implementation from __builtins__. But that is a lot more work. =) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2491] io.open() handles errors differently on different platforms
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed r65343: os.fdopen accepts the same parameters as io.open(). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3481] Length of struct.pack('HL', 1, 1) incorrect (8 instead of 6 bytes)
New submission from Dominique Parolin [EMAIL PROTECTED]:
Python Versions tested:
Windows 2.5.2 (r252:60911)
Debian Linux Python 2.4.4
Example:
import struct
struct.pack('HL', 1, 1)
results in '\x01\x00\x00\x00\x01\x00\x00\x00'
although '\x01\x00\x01\x00\x00\x00' was expected.
if concatenated or done separately
struct.pack('H', 1) + struct.pack('L', 1)
result is as expected '\x01\x00\x01\x00\x00\x00'
or
'\x01\x00' and '\x01\x00\x00\x00' respectively
Error:
Length is 8 where it should be 6
This is as well true for hl, hL and Hl.
Free description:
I could not find another error regarding that, nor any information using
popular search.
Further no explanation found why that might be valid behaviour.
Regards,
Dominique
--
components: Library (Lib)
messages: 70535
nosy: dparolin
severity: normal
status: open
title: Length of struct.pack('HL', 1,1) incorrect (8 instead of 6 bytes)
type: behavior
versions: Python 2.4, Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3481
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3481] Length of struct.pack('HL', 1, 1) incorrect (8 instead of 6 bytes)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The struct module is correct.
You see here the result of alignment: the address of a long is always
a multiple of the size of a long.
The struct module mimics the C compiler: a struct { short x; long y;
}, will actually occupy 8 bytes in memory (on a 32bit processor).
There are two padding bytes, that are not used.
--
nosy: +amaury.forgeotdarc
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3481
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Skip Montanaro [EMAIL PROTECTED] added the comment: I added a comment to Andrii's patch and added simple test cases which check to make sure the way Nick and I currently use the DictReader class (or at least envision using it) still works. Added file: http://bugs.python.org/file11021/csv.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Changes by Skip Montanaro [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10978/csv.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Skip Montanaro [EMAIL PROTECTED] added the comment: Andrii, If my view of the Python 3.0 development process is correct and this change makes it into the 2.6 code, one of the 3.0 developers will merge to the py3k branch. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Jesse Noller [EMAIL PROTECTED] added the comment: Ben's incref error != the connection refused error. Here's some information from Scott Leerssen who is using the original .52 code: Hi Jesse, I am having some trouble with the processing module (0.52) and thought you might be of some help since you were so involved with it in the PEP process. I have a queue of Process objects from which a runner thread pulls and starts processes. The producers for the queue are many, many threads. I'm seeing some very odd behavior when lots of processes try to start while others are being reaped at the same time. I see tracebacks that look like the one below, and also occasionally get hangs where the process module seems to take over the GIL and never give it back. I did find a race condition bug in process.py where a _cleaner function is run in start(), potentially joining on processes that other threads may also be joining at the same time, which leads to KeyError exceptions coming from _cleaner. I mutexed all my starts and joins to get around that for now, but am stumped on the issue below. Does it look familiar to you? Thanks, and feel free to shrug and reply beats me. Scott [dmbd:32451:-1236096096] 2008-07-31 16:52:10,609 SYSMESG Process Process-24: [dmbd:32451:-1236096096] 2008-07-31 16:52:10,612 SYSMESG [dmbd:32451:-1236096096] 2008-07-31 16:52:10,613 SYSMESG Traceback (most recent call last): [dmbd:32451:-1236096096] 2008-07-31 16:52:10,613 SYSMESGFile /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/process.py, line 224, in _bootstrap [dmbd:32451:-1236096096] 2008-07-31 16:52:10,615 SYSMESG _runAfterForkers() [dmbd:32451:-1236096096] 2008-07-31 16:52:10,616 SYSMESGFile /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/process.py, line 300, in _runAfterForkers [dmbd:32451:-1236096096] 2008-07-31 16:52:10,617 SYSMESG func(obj) [dmbd:32451:-1236096096] 2008-07-31 16:52:10,617 SYSMESGFile /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/managers.py, line 806, in _afterFork [dmbd:32451:-1236096096] 2008-07-31 16:52:10,620 SYSMESG self._incref() [dmbd:32451:-1236096096] 2008-07-31 16:52:10,621 SYSMESGFile /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/managers.py, line 760, in _incref [dmbd:32451:-1236096096] 2008-07-31 16:52:10,621 SYSMESG dispatch(connection, None, 'incref', (self._id,)) [dmbd:32451:-1236096096] 2008-07-31 16:52:10,622 SYSMESGFile /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/managers.py, line 92, in dispatch [dmbd:32451:-1236096096] 2008-07-31 16:52:10,623 SYSMESG raise result [dmbd:32451:-1236096096] 2008-07-31 16:52:10,624 SYSMESG RemoteError: --- Remote Traceback (most recent call last): File /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/managers.py, line 190, in handleRequest result = func(c, *args, **kwds) File /opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site- packages/processing/managers.py, line 404, in incref self.id_to_refcount[ident] += 1 KeyError: 2880341100L ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2260] conditional jump to a POP_TOP optimization
Jack Diederich [EMAIL PROTECTED] added the comment: +0 * The peepholer comment promises Optimizations are restricted to simple transformations occuring within a single basic block. and this goes beyond that. You could patch that comment. * This needs a matching patch to Lib/test/test_peepholer.py * Deeply nested ifs suffer a flat penalty because the unconditional jump peepholer figures this out after the first extra POP_TOP (notice the JUMP_ABSOLUTE in your second disassembly). * I noticed the NOP assignment is commented out in your patch, was that unsafe? I searched for old threads on the peephole optimizer and came up with these: Skip Montanaro's paper http://www.webfast.com/~skip/python/spam7/optimizer.html Two old python-dev threads http://www.gossamer-threads.com/lists/python/dev/645669 http://www.gossamer-threads.com/lists/python/dev/645669 I was hoping to find out if writing a bytecode optimizer in python had been discussed because a generic version of your optimization would be really easy to write in pure python (using a dict for the jump table, for instance). I found nothing; my search terms might have been insufficient. -- nosy: +jackdied ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2260 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2676] email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input
Jack Diederich [EMAIL PROTECTED] added the comment: Augmented version of Daniel's patch. This makes an internal function that does the same work. It uses txt.find() instead of split() or partition() because for pathologically long strings find() is noticeably faster. It also does the strip() before the lower() which helps with evilly long strings. I didn't remove the module global paramre because an external module might be using it. I did update its comment. Do bugfixes get applied to 2.6 or 3.0? I'm a bit out of practice. -- nosy: +jackdied Added file: http://bugs.python.org/file11022/email.message.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2676 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10862/issue2275-py26.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10863/issue2275-py3k.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11023/issue2275-py26.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
