[issue2275] urllib2 header capitalization

Senthil <[EMAIL PROTECTED]> added the comment: I am submitting a revised patch for this issue. I did some analysis on the history of this issue and found that this .capitalize() vs .title() changes had come up earlier too ( issue1542948)and decision was taken to: - To retain the Header format in

[issue2275] urllib2 header capitalization

Changes by Senthil <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11024/issue2275-py3k.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2275] urllib2 header capitalization

Changes by Senthil <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11023/issue2275-py26.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2275] urllib2 header capitalization

Changes by Senthil <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10863/issue2275-py3k.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2275] urllib2 header capitalization

Changes by Senthil <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10862/issue2275-py26.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[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()

[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_peepho

[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 si

[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 PROTECTE

[issue3436] csv.DictReader inconsistency

Changes by Skip Montanaro <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10978/csv.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[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

[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 by

[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 con

[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]> ___

[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 c

[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 a

[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 <[EM

[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

[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 add

[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 t

[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]>

[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 hav

[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__(

[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 PR

[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 e

[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

[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 PROTECT

[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. > > ___

[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: +ama

[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]> ___

[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]> ___ __

[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]> ___ ___

[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 PROTE

[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]> ___ ___ Python-bugs-list mailing l

[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. ___ Py

[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]> _

[issue3479] unichr integer overflow

New submission from Ralf Schmitt <[EMAIL PROTECTED]>: unichr(2**32) results in a unicode string containing a 0 byte: {{{ ~/mwlib.hg/tests/ python Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help

[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

[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

[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]> ___ _

[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 help

[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 ar

[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]> ___ ___

[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 pat

[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". _

[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

[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(

[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]> ___ ___

[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 op

[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]> ___ ___ Py

[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]> _

[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]> ___

[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

[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/

[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]>

[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

[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 thr

[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()) ___ Pyth

[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]> __

[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 __

[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 P

[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]> ___ __

[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/_e