[issue2292] Missing *-unpacking generalizations

Thomas Wouters <[EMAIL PROTECTED]> added the comment: No, it's what you asked for in msg63551: > How about dicts? > kwds = {'z': 0, 'w': 12} > {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, 'w': 12} (unpacking of dicts in dicts.) __ Tracker <[EMAIL PROTECT

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I've attached my patch that I want to commit. The main change from filethread4 is some cleanup in file_test to make it run a lot faster and add verbose mode output to indicate how well it is actually testing the problem (counting the times

[issue508157] urllib.urlopen results.readline is slow

Aren Olson <[EMAIL PROTECTED]> added the comment: I can indeed confirm that this change creates a HUGE speed difference. Using the code found at [1] with python2.5 and apache2 under Ubuntu, changing the buffer size to 4096 improved the time needed to download 10MB from 15.5s to 1.78s, almost 9x f

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Well, so much for the first attempt. I'll see what it takes to use > something else, like ac_compiler_gnu. Unless Gregory's suggestion > qualifies. I would prefer to see the configure test for gcc be recorded and passed through, over t

[issue508157] urllib.urlopen results.readline is slow

Daniel Diniz <[EMAIL PROTECTED]> added the comment: Well, this issue is still hurting performance, the most recent example was with a developer of a download manager. I suggest adding a buffer size argument to HTTPResponse.__init__ (defaulting to zero), along with docs that explain the problems

[issue2292] Missing *-unpacking generalizations

Guido van Rossum <[EMAIL PROTECTED]> added the comment: What's dict unpacking? I hope it's not an implementation of this sad idea posted recently: {'a': x, 'b': y} = {'a': 42, 'b': 'hello'} # Same as x, y = 42, 'hello' :-) __ Tracker <[EMAIL PROTECTED]>

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm reviewing this patch now and plan to commit it after some testing. A couple comments: I'd rename your sts variables to status. Also FYI: Your use of volatile on the int unlocked_count member of PyFileObject does not do what you think

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

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: _wstat64 does not exist in VC6, so used GetFileAttributesW instead. Added file: http://bugs.python.org/file9957/ocean.zip __ Tracker <[EMAIL PROTECTED]> __

[issue2560] removal of stale code from myreadline.c

New submission from Joseph Armbruster <[EMAIL PROTECTED]>: This patch removes a stale for loop from myreadline.c: http://svn.python.org/projects/python/trunk @ 62180 -- components: Interpreter Core files: myreadline.patch keywords: patch messages: 65015 nosy: JosephArmbruster severity:

[issue1753245] Add RegEnableReflectionKey and RegDisableReflectionKey

Mark Hammond <[EMAIL PROTECTED]> added the comment: Been sitting here for a while without comment, so: Sending_winreg.c Committed revision 62180. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]>

[issue2292] Missing *-unpacking generalizations

Changes by Thomas Wouters <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9673/morestar.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-

[issue2292] Missing *-unpacking generalizations

Thomas Wouters <[EMAIL PROTECTED]> added the comment: Updated patch: reworked some internals, and added generalization of functioncalls after talking with Guido. *args is now considered just another positional argument, and can occur anywhere in the positional argument section. It can also occur

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Well, so much for the first attempt. I'll see what it takes to use something else, like ac_compiler_gnu. Unless Gregory's suggestion qualifies. Also, I am using SUN's compilers on Solaris 10 for 'political' and some technical reasons. An

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: agreed, do not check to see if the string is == 'gcc'. Instead, actually execute the CC compiler with a -v flag and test if 'gcc version' in output. something like this (but split into a few statements for readability): if 'gcc version' n

[issue2541] Unicode escape sequences not parsed in raw strings.

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: What about the "raw-unicode-escape" codec? Can we leave it different from raw strings literals? __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Thomas Heller <[EMAIL PROTECTED]> added the comment: I'm curious: Why do you insist on using the sun compiler? Are there political or technical reasons? Another thing: in principle it should be possible to build a libffi shared library with gcc, and use it in a sun-c compiled python build. At

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think this is incorrect; CC might also be "gcc -pipe" or "/usr/local/bin/gcc", or some such, and would still be gcc (perhaps even /usr/local/bin/cc). __ Tracker <[EMAIL PROTECTED]>

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Attached is one attempt to avoid building the _ctypes module if the compiler is not gcc: a patch for Python 2.6a2 with just 2 changes for setup.py based on the value of config variable CC. -- keywords: +patch Added file: http://bugs.

[issue2128] sys.argv is wrong for unicode strings

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This is now fixed in r62178 for Py3k. For 2.6, I don't think fixing it is feasible. -- resolution: -> fixed status: open -> closed versions: -Python 2.6 __ Tracker <[EMAIL PROTECTED]>

[issue2240] setitimer, getitimer wrapper

Guilherme Polo <[EMAIL PROTECTED]> added the comment: FreeBSD's man page for setitimer/getitimer doesn't look different from the one in Linux. But.. both tests assumes the computer is not so fast that it finishes "for i in xrange(1)" before the timer expire, maybe it was not the case in

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Daniel Diniz <[EMAIL PROTECTED]> added the comment: New patch. I added the new rule and changed the old behavior to be wrong (a bit) less often. It may mess with code that depended on the previous wrong results. Given the (AFAIK) exemplificative nature of this file, this should not be a big probl

[issue2240] setitimer, getitimer wrapper

Guilherme Polo <[EMAIL PROTECTED]> added the comment: I'm investigating the problem loewis, thanks for reporting. But it would be better if someone with running FreeBSD could help me there, in case I find the cause for this. Also some changes were made to the original patch: neal.norwitz did a

[issue2559] atom sorting error when buiding ctypes

New submission from Skip Montanaro <[EMAIL PROTECTED]>: I recently started getting the following error when building the trunk on Mac OS X Leopard: ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Would it be OK to not > do any of that on Solaris, if the compiler is not gcc? That would be fine. __ Tracker <[EMAIL PROTECTED]> __

[issue2240] setitimer, getitimer wrapper

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Reopening. Apparently, the tests fail on FreeBSD; see http://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/builds/77/step-test/0 Can you please look into this? -- status: closed -> open __

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: The setup.py module contains method detect_ctypes on line 1546 which handles the ctypes module building and testing. Would it be OK to not do any of that on Solaris, if the compiler is not gcc? Also, SUN Studio 12, the latest edition of t

[issue2541] Unicode escape sequences not parsed in raw strings.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I made the requested improvements and mentioned it in NEWS. Is there worth putting in the tutorial, since it mentions Unicode strings and raw strings? Added file: http://bugs.python.org/file9952/py3k_raw_strings_unicode_escapes3.patch __

[issue2558] Document pickle protocol 3

Guilherme Polo <[EMAIL PROTECTED]> added the comment: Sent wrong file before, this is the correct one. -- keywords: +patch Added file: http://bugs.python.org/file9951/pickle_protocol3.rst.diff __ Tracker <[EMAIL PROTECTED]>

[issue2558] Document pickle protocol 3

Changes by Guilherme Polo <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9950/pickle_protocol3.rst __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2558] Document pickle protocol 3

Guilherme Polo <[EMAIL PROTECTED]> added the comment: There. -- nosy: +gpolo Added file: http://bugs.python.org/file9950/pickle_protocol3.rst __ Tracker <[EMAIL PROTECTED]> __

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: For ctypes to compile with the SUN's C compiler, there is quite a bit of tricky asm code which needs to be ported (and tested). Most of that is in libffi and that library is only supported with gcc, it seems. But that is not mentioned expl

[issue2558] Document pickle protocol 3

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- assignee: georg.brandl -> gvanrossum nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Pyt

[issue2558] Document pickle protocol 3

New submission from Georg Brandl <[EMAIL PROTECTED]>: A new pickle protocol was added to Py3k; it needs to be mentioned in the docs. -- assignee: georg.brandl components: Documentation messages: 64993 nosy: georg.brandl severity: normal status: open title: Document pickle protocol 3 vers

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned. So the proper fix for that would be to port it to SunPro, of course. > The > only thing which can be done is avoid building the _ctypes module if the > compiler is no

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- assignee: georg.brandl -> gvanrossum nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Pyt

[issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings

Georg Brandl <[EMAIL PROTECTED]> added the comment: Thank you, fixed in r62171. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue2541] Unicode escape sequences not parsed in raw strings.

Georg Brandl <[EMAIL PROTECTED]> added the comment: The segment "use different rules for interpreting backslash escape sequences." should be killed entirely, and the whole rule told here. Also, a few paragraphs later there are more references to raw strings, e.g. "When an ``'r'`` or ``'R'`` pref

[issue2546] Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270

George Verbitsky <[EMAIL PROTECTED]> added the comment: Thank you, Amaury, very much for helping me with this one. George Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: Amaury Forgeot d'Arc added the comment: The crash is because of an error in your C code: in backend.c:: void backend(ch

[issue2556] changing sys.dont_write_bytecode has not effect

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue2556] changing sys.dont_write_bytecode has not effect

Georg Brandl <[EMAIL PROTECTED]> added the comment: Sorry, I can't see what's wrong here. See import.c which indeed uses PySys_GetObject to retrieve the value of dont_write_bytecode. __ Tracker <[EMAIL PROTECTED]> ___

[issue2557] \u and \U in raw strings have regressed in 3.0a4

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: The was not a mistake, it was done on purpose since there would otherwise have been no way to add non-ASCII Unicode code points to a raw Unicode literal, rendering raw Unicode literals pretty useless. Even if you use UTF-8 as source code

[issue2541] Unicode escape sequences not parsed in raw strings.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: "not treated specially" it is! Added file: http://bugs.python.org/file9948/py3k_raw_strings_unicode_escapes2.patch __ Tracker <[EMAIL PROTECTED]>

[issue2541] Unicode escape sequences not parsed in raw strings.

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Instead of "ignored" (which might be read ambiguously) how about "not treated specially"? You also still need to add some words to whatsnew. __ Tracker <[EMAIL PROTECTED]>

[issue2541] Unicode escape sequences not parsed in raw strings.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: How's this? -- keywords: +patch Added file: http://bugs.python.org/file9947/py3k_raw_strings_unicode_escapes.patch __ Tracker <[EMAIL PROTECTED]>

[issue2548] Undetected error in exception handling

Brett Cannon <[EMAIL PROTECTED]> added the comment: Neal has the memory of an elephant or something. Yes, I dealt with a similar issue where the recursion limit was hit, but then normalizing the exception just caused it to hit it again. I thought I changed it such that normalizing an exception

[issue2541] Unicode escape sequences not parsed in raw strings.

Guido van Rossum <[EMAIL PROTECTED]> added the comment: The docs still need to be updated! An entry in what's new in 3.0 should also be added. -- assignee: -> georg.brandl components: +Documentation -Unicode nosy: +georg.brandl, gvanrossum status: closed -> open __

[issue2349] Py3K warn against assigning to True/False

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Brett, shall I apply? __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsub

[issue2557] \u and \U in raw strings have regressed in 3.0a4

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: fixed in r62165. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2541] Unicode escape sequences not parsed in raw strings.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Sorry, Guido said this is not allowed: http://mail.python.org/pipermail/python-3000/2008-April/012952.html. I reverted it in r62165. -- resolution: fixed -> rejected __ Tracker <[EMAIL PROTECTED]> <

[issue2557] \u and \U in raw strings have regressed in 3.0a4

Changes by Guido van Rossum <[EMAIL PROTECTED]>: -- components: +Interpreter Core __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue2557] \u and \U in raw strings have regressed in 3.0a4

Changes by Guido van Rossum <[EMAIL PROTECTED]>: -- title: \u and \U in raw strings have reverted -> \u and \U in raw strings have regressed in 3.0a4 __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2557] \u and \U in raw strings have reverted

New submission from Guido van Rossum <[EMAIL PROTECTED]>: In 2.x, \u and \U are interpreted as Unicode escapes in raw Unicode strings. That was a mistake, but we can't fix it (except when using "from __future__ import unicode_literals"). In 3.0, \u or \U in a raw string should have no

[issue2556] changing sys.dont_write_bytecode has not effect

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: According to the 2.6 docs, says you can set it yourself to control bytecode generation. That doesn't work because the dont_write_bytecode flag is set from command option and never looked at again. Either we should remove this misleading i

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned. The only thing which can be done is avoid building the _ctypes module if the compiler is not gcc. I did look at fixing that but have not found the proper way to do that.

[issue2526] str.format() :n format does not appear to work for int and float

Eric Smith <[EMAIL PROTECTED]> added the comment: The same issue exists with floats: # continuing the example >>> locale.format("%g", 12345, True) '12,345' >>> "{0:n}".format(12345.0) '12345' The same issue exists in 2.6. -- title: str.format() :n format does not appear to work -> str.

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

Jean Brouwers <[EMAIL PROTECTED]> added the comment: Don't change that line. It is obviously clear already, if someone does read it. I obviously did not. /Jean __ Tracker <[EMAIL PROTECTED]> __

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: *testing stack overflow:* maybe? -- nosy: +benjamin.peterson __ Tracker <[EMAIL PROTECTED]> __

[issue1164742] Tkdnd.py crashes due to read-only attributes

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> _ ___

[issue2530] Document IO module

Georg Brandl <[EMAIL PROTECTED]> added the comment: Great! __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue2546] Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The crash is because of an error in your C code: in backend.c:: void backend(char *output_filename) { C2py("backend", 1, output_filename); } But your C2py function expects a variable number of PyObject*. I found thi

[issue1164742] Tkdnd.py crashes due to read-only attributes

Guilherme Polo <[EMAIL PROTECTED]> added the comment: This was fixed on rev 39219 (2 years and 8 months ago) This surely could be closed by now. -- nosy: +gpolo _ Tracker <[EMAIL PROTECTED]> __

[issue2526] str.format() :n format does not appear to work

Eric Smith <[EMAIL PROTECTED]> added the comment: I'm looking into it. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

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

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: I don't know why, but /D "MODULE_NAME=\"sqlite3\"" is troublesome. VC6 IDE expands this to #define MODULE_NAME " sqlite3". To workaround this, I used /D MODULE_NAME=\"sqlite3\" instead in sqlite3.dsp. Added file: http://bugs.python.org/fi