[issue3482] re.split, re.sub and re.subn should support flags

New submission from Benoit Thiell <[EMAIL PROTECTED]>: Given that the search operations support flags, it seems natural for a developer that the other functions in the module support flags as well. So when running "re.split(pattern, string, re.I)", the split() command seems to not work and don't

[issue3482] re.split, re.sub and re.subn should support flags

Changes by Benoit Thiell <[EMAIL PROTECTED]>: -- components: +Regular Expressions type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3392] subprocess fails in select when descriptors are large

Changes by David Kågedal <[EMAIL PROTECTED]>: -- nosy: +d_kagedal ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailin

[issue3436] csv.DictReader inconsistency

Andrii V. Mishkovskyi <[EMAIL PROTECTED]> added the comment: Oh, so this is how the process looks like... /me removes patches I've uploaded both py3k and trunk patches just because I'm fixing things the other way round -- first I write a patch for 3.0 and only after that I backport it to 2.6. Stu

[issue3436] csv.DictReader inconsistency

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11016/issue3436.py3k.csv.py.diff ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3436] csv.DictReader inconsistency

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11017/issue3436.trunk.csv.py.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2260] conditional jump to a POP_TOP optimization

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2819] Full precision summation

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Toned down note in docs (at Raymond's request) in r65366. While I'd really like to see an lsum-based version go in instead, I think it's too close to the release to make this change right now. There was also originally some talk of a comple

[issue2260] conditional jump to a POP_TOP optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: While this patch is interesting, I think it would be more efficient to introduce variants of JUMP_IF_FALSE and JUMP_IF_TRUE which pop their argument rather than leaving it on the stack (like I did in #2459). -- nosy: +pitrou

[issue3436] csv.DictReader inconsistency

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Skip's patch looks good to me (as Skip discovered, I left out the necessary step of putting the first row back into an iterable before invoking chain in my example code) ___ Python tracker <[EMAIL PROTECTED]>

[issue2690] Precompute range length

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Guido, does that mean we can apply this patch to get the cleaner list-like behaviour for 3.0, and then work on the sq_item/sq_len fixes for 3.1 as a separate issue? ___ Python tracker <[EMAIL PROTECTED]>

[issue2860] re module fails to handle byte strings

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: This is a duplicate of #3231 and was fixed in r65185. -- nosy: +pitrou resolution: -> duplicate status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: The problem does still exist (Python 2.6b2). I attached a patch for Tkinter.py which addresses this problem. It is the same as in the first proposed fix, but adds an additional check whether the menu item has a 'command' property. I also

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I finally found some more time to look at this. I cut down the test-suite to try to find a minimal failing example. I can fairly reliably make a debug build of the trunk crash using the following nine lines import multiprocessing.managers

[issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: This is a duplicate of #3131. -- nosy: +benjamin.peterson resolution: -> duplicate status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue3131] 2to3 can't find fixes_dir

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Installation of PatternGrammar pickle is now fixed in r65368 and r65369. HWJ, please don't report multiple problems in a single tracker issue; instead, create separate tracker issues for independent problems. -- nosy: +loewis _

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Assertion failed: (bp != NULL), function PyObject_Malloc, file > Objects/obmalloc.c, line 755. This one gives one probable cause of the problem: - in Modules/_multiprocessing/connection.h, connection_send_obj() releases the GIL arou

[issue3139] bytearrays are not thread safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Amaury, I think the issue of thread-safety of the io library should be decoupled from this issue. I don't think it is release-critical that the io library is thread-safe (and even if it is release-critical, the problem should be tracked in a

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > This is wrong (the GIL must be held when using the PyMem_* and > PyObject_* functions), and is probably the cause of the failed assertion. This sounds quite likely. I just managed (using the low-tech method of setting a static variable o

[issue3139] bytearrays are not thread safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Selon "Martin v. Löwis" <[EMAIL PROTECTED]>: > > Amaury, I think the issue of thread-safety of the io library should be > decoupled from this issue. I don't think it is release-critical that the > io library is thread-safe (and even if it is

[issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error

jan matejek <[EMAIL PROTECTED]> added the comment: > "as it doesn't seem /dev/shm is the culprit" Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot) environment, so for me it actually was the culprit. Perhaps you should recheck your buildbots? -- nosy: +matejcik __

[issue3139] bytearrays are not thread safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I have now updated the patch to fix the socket bug, and the rejects bytearray for t#. As for making Py_buffer own a reference to the object: what should be the semantics for PyObject_ReleaseBuffer? I see the following options: - Drop PyObjec

[issue3139] bytearrays are not thread safe

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10969/s_star.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a patch that fixes the problem for me. It releases the GIL around the calls to _conn_sendall within conn_send_string, instead of releasing the GIL for the whole call to conn_send_string. -- keywords: +patch Added file: http:/

[issue3139] bytearrays are not thread safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Selon "Martin v. Löwis" <[EMAIL PROTECTED]>: > > As for making Py_buffer own a reference to the object: what should be > the semantics for PyObject_ReleaseBuffer? I see the following options: > - Drop PyObject_ReleaseBuffer > - make it DECREF

[issue3476] BufferedWriter not thread-safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I don't think the proposed patch (file11012) makes it thread-safe, and I believe you cannot get it thread-safe without using thread synchronization. For example, if two threads simultaneously determine that there is still space left (len(b)

[issue3476] BufferedWriter not thread-safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Hi, Selon "Martin v. Löwis" <[EMAIL PROTECTED]>: > > I don't think the proposed patch (file11012) makes it thread-safe, and I > believe you cannot get it thread-safe without using thread synchronization. I should have precised that in the c

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: To be complete, the patch should also deal with conn_recv_string() which has the same problem. And please do not forget the win32 implementation, in pipe_connection.c. ___ Python tracker <[EMAIL PROTE

[issue3483] sys.stdin.read won't return on EOF

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: $ ./python.exe -c "import sys; sys.stdin.read()" ^D In 2.6, this returns, but in 3.0, it still hangs despite having gotten EOF. When a KeyboardInterrupt is given, this is the traceback: ^CTraceback (most recent call last): File "", li

[issue3483] sys.stdin.read won't return on EOF

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I'm sorry. This is my oversight. -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue3484] Sphinx tests fail because of missing dir

New submission from Rob Cakebread <[EMAIL PROTECTED]>: When I try to run the unit tests with tests/run.py they fail because this directory is missing: tests/root/_build If I simply create the directory and run the tests, they pass. Running Sphinx test suite... EEE... ==

[issue3484] Sphinx tests fail because of missing dir

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Sorry, time machine! I fixed this just 2 days ago. :) -- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Thanks, Amaury! How's this? I have no access to a Windows machine, so this patch is untested on Windows. Added file: http://bugs.python.org/file11028/issue3399_2.patch ___ Python tracker <[EMAIL PROTECT

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I'm also seeing the incref error occasionally, on OS X 10.5.4: == ERROR: test_remote (__main__.WithManagerTestRemoteManager) -

[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X

New submission from Isaac Morland <[EMAIL PROTECTED]>: $ python Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from os.path import normcase >>> normcase ('aB') 'aB' >>> >Fr

[issue3006] subprocess.Popen causes socket to remain open after close

Kevin Watters <[EMAIL PROTECTED]> added the comment: I found a workaround for this issue (attached) via the kernel32.dll function SetHandleInformation. You can patch the socket class to set all newly created sockets as uninheritable. It's not perfect--another thread could still spawn a subproces

[issue3486] bytes.join does not accept a sequence of bytearrays

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: This works in py3k but not in 2.x. I don't know if it is deliberate: Python 3.0b2+ (py3k, Jul 27 2008, 12:52:40) [GCC 4.3.1 20080626 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> b"".joi

[issue3487] sre "bytecode" verifier

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Attached is a verifier for the binary code used by the _sre module (this is often called bytecode, though to distinguish it from Python bytecode I put it in quotes). I wrote this for Google App Engine, and am making the patch available as

[issue3139] bytearrays are not thread safe

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Martin, There is a small issue with the patch: in the "w#" format handler, bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be &res (there is a compilation warning on windows), And a few lines after, in the "if (*for

[issue3486] bytes.join does not accept a sequence of bytearrays

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I suppose this is because bytes is simply aliased to str. I propose we just leave it as is. The ultimate solution is probably backporting th py3k PyBytes type. -- nosy: +benjamin.peterson ___ Py

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Mark, There are 3 semicolons missing in your patch, in pipe_connection.c, just after the calls to WriteFile and ReadFile. After this, it compiles and runs correctly. Tests pass. Note that on Windows, your "nine lines" cannot work as is,

[issue3488] Provide compress/uncompress functions on the gzip module

New submission from Anand B Pillai <[EMAIL PROTECTED]>: Python has great in-built support for all sorts of text compression including bzip, gzip, tarfile and other general purpose modules like zlib etc. Of these, I have a gripe with gzip - it does not provide a simple way of compressing/uncompre

[issue3489] add rotate{left,right} methods to bytearray

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: While tweaking the BufferedWriter implementation it came to me that it would be useful to have rotate_left and rotate_right methods on bytearray, so as to rotate the array by a number of bytes without any wasteful memory allocations and cop

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Jesse Noller <[EMAIL PROTECTED]> added the comment: I added the semicolons Amaury, and have it teed up in my local repo for submit. Can you review this diff just to confirm? Added file: http://bugs.python.org/file11031/add_semicolons.diff ___ Python tracker

[issue2688] Error when nesting many while loops

Jack Diederich <[EMAIL PROTECTED]> added the comment: This was fixed in more recent versions of 2.5, it now raises a "SystemError: too many statically nested blocks" Thanks for the tip Guilherme. Marking closed. -- nosy: +jackdied resolution: -> out of date status: open -> closed ___

[issue2935] rfc822.py line 395 strings connection

Jack Diederich <[EMAIL PROTECTED]> added the comment: This is a bug in the external ClientCookie module (and their website hasn't been updated since 2006). Marking closed. -- nosy: +jackdied resolution: -> invalid status: open -> closed ___ Python t

[issue3139] bytearrays are not thread safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le vendredi 01 août 2008 à 17:53 +, Amaury Forgeot d'Arc a écrit : > There is a small issue with the patch: in the "w#" format handler, > bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be > &res (there is a compilation

[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X

Ned Deily <[EMAIL PROTECTED]> added the comment: "Of course, Mac OS X is both Unix and case-insensitive" Not so. Case-{in|}sensitivity is an attribute of HFS+ file systems that is specifiable when a file system is created; it's true that the default is still case-insensitive. There are also ot

[issue2819] Full precision summation

Tim Peters <[EMAIL PROTECTED]> added the comment: Mark, changing API is something to avoid after beta cycles begin (so, e.g., it's late in the game to /add/ a new API, like a new method for complex summation). But there's no particular reason to fear changing implementation for an API that's alr

[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X

Isaac Morland <[EMAIL PROTECTED]> added the comment: Ok, good point. Perhaps the documentation should be updated to clarify that Mac OS is treated as Unix even though a default Mac OS X installation will have a case-insensitive file system. Wouldn't it be possible for a Windows machine to have

[issue3139] bytearrays are not thread safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: I'm attaching a patch for getargs.c and another patch for the codecs module. Added file: http://bugs.python.org/file11032/codecs.patch Added file: http://bugs.python.org/file11033/getargs.patch ___ Python

[issue3139] bytearrays are not thread safe

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: -giampaolo.rodola ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs

[issue3469] Umlauts make conf.latex_documents fail

Georg Brandl <[EMAIL PROTECTED]> added the comment: Indeed, you're correct with that. This is now fixed in the 0.4 branch with r65375. -- resolution: -> fixed status: pending -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4

Jesse Noller <[EMAIL PROTECTED]> added the comment: I've committed this as-is based off my last patch. I will watch the buildbots for failures. Mark/Amaury - if I see you guys at pycon, I owe you a drink. -- resolution: -> fixed status: open -> closed ___

[issue3476] BufferedWriter not thread-safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Attaching a new patch with better performance characteristics than my previous one, and the non-blocking test rewritten in a sane way. Some timeit runs: -s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*1" "for i in xrange(100): f.write(s

[issue3228] mailbox.mbox creates files with execute bit set

Jack Diederich <[EMAIL PROTECTED]> added the comment: mailbox.py uses os.open instead of the builtin open() because it wants to pass the exclusive flag (O_EXCL). As a result your 0077 umask gets combined with the default of 0777 like this: 0777 & ~0077 == 0700 == '-rwx--' So you probably w

[issue2951] ElementTree parsing bus error (but only from mod_python)

Jack Diederich <[EMAIL PROTECTED]> added the comment: It is a common apache problem. Elementree imports an expat parser (presumably cElementree doesn't) and different versions of expat play together very poorly. Lots of apache modules load one xml lib version or another and they tend to step on

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

Josiah Carlson <[EMAIL PROTECTED]> added the comment: The current revision of 3.0 handles the case where reading from the socket returns a Python 3.0 str object, which it then translates into bytes objects. This is sufficient for passing the 3.0 unittests. See asynchat.async_chat.use_encoding a

[issue3488] Provide compress/uncompress functions on the gzip module

Anand B Pillai <[EMAIL PROTECTED]> added the comment: Uploading a file containing two functions which can be used to provide compress/uncompress on gzip. This is not a patch to gzip.py, but a stand-alone file. It this looks fine, I will make a patch. Added file: http://bugs.python.org/file11035

[issue3139] bytearrays are not thread safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I don't know, is there supposed to be a semantic difference between > PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it. There are existing callers of it which would need to be changed, perhaps outside the core also; plu

[issue3487] sre "bytecode" verifier

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: Based on my understanding of the above and PyDev discussions, I see the arguments in favor of quick inclusion as being the following: 1. This will be user invisible, so it is not a new interface feature. 2. This will prevent possible interpret

[issue3473] In function call, keyword arguments could follow *args

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I will not have internet access for the next week. Raymond, would you take care of this issue? -- assignee: amaury.forgeotdarc -> rhettinger ___ Python tracker <[EMAIL PROTECTED]>

[issue3476] BufferedWriter not thread-safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I should have precised that in the context of this issue, "thread-safe" does > not > mean "produces perfectly correct output" but simply "does not raise exceptions > when using the same buffered object from two different threads". In that

[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: On Windows, case-insensitivity is part of the API, not of the file system. NTFS itself is case-sensitive, and there are case-sensitive subsystems on top of it (e.g. the POSIX subsystem, Interix). Win32, when calling the file system, asks for

[issue3476] BufferedWriter not thread-safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le vendredi 01 août 2008 à 21:51 +, Martin v. Löwis a écrit : > With the status quo, people have at least a chance of learning that the > library is not thread-safe. If the shallow problems are resolved, people > will cry FOUL loudly when

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

Daniel Arbuckle <[EMAIL PROTECTED]> added the comment: > From what I understand, the OP wants to be able to pass unicode strings > across a network connection. That's incorrect. At the time I formulated this patch, asyncore/asynchat were slated for removal from the standard lib unless somebody

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Asyncore and asynchat are not going to be removed, and were not being seriously discussed as being removable in Python 3.0 since January of 2007 when I took over maintenance. If there was a miscommunication in an email thread on python-3000 o

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: For the connection refused error, the following script fails for me (again, on OS X 10.5.4) with the message: errno: [Errno 61] Connection refused on most runs. (If xrange(10) is replaced by a smaller range like xrange(4) then the script

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

Daniel Arbuckle <[EMAIL PROTECTED]> added the comment: As of December 2007, Guido did not believe that you or anyone else cared enough about asyncore/asynchat to update them to py3k: http://mail.python.org/pipermail/python-dev/2007-December/075574.html Thankfully there's been a resurgence of act

[issue3459] optimize bytes.join()

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: How much does the optimization speed up (or slow down?) a more normal case when it is applicable? bl = [b'', b'a'] How much does the optimization slow down the normal case where it is not applied? bl = [b'a']*2 bl = [b'a']*1 Could

[issue3487] sre "bytecode" verifier

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > 3. Google considered this enough of a potential problem to pre-emptively > fix it. Now that that problem has been publicly exposed, other careful > users will expect it to be fixed and will find Python more attractive > when it has been.

[issue3459] optimize bytes.join()

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: bl = [b'', b'a'] gives a 20% speedup: before patch: 100 loops, best of 3: 0.443 usec per loop after patch: 100 loops, best of 3: 0.349 usec per loop (20% speedup) bl = [b'a']*2 gives a 2% slowdown: before patch: 100 loops, best

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Looks like something in semaphore.c needs fixing, but I've no idea what. I take that back. It's nothing to do with semaphore.c. I'll keep trying. ___ Python tracker <[EMAIL PROTECTED]>

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Are you looking at the conn refused or the incref error? ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3463] make life.py use more rendering characters

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: Summary: This patch makes a non-essential change to a curses demo. It also reverses several 2.x to 3.0 edits, turning it back to 2.x code. So the current version must be rejected. Even if corrected, I would still recommend closing. To me,

[issue2819] Full precision summation

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: Comment: as a user (on x86) I agree with Tim. I could almost see the new version as a bugfix. Question: I see "math module patch committed, r63542" in May 22. But in 3.0b2, there is no math.fsum and math.sum seems to be a wrapper for builti

[issue3476] BufferedWriter not thread-safe

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Well, if that resolution is prefered, I think it should be integrated to > the builtin print function, rather than forcing users to monkeypatch it > (but a debugging facility directly calling sys.stdout.write or > equivalent will not be hel

[issue3490] Example Code Error in Tutorial Documentation

New submission from Adam <[EMAIL PROTECTED]>: In section 4.4 of the Python Tutorial (http://docs.python.org/tut/node6.html) there is a code example using prime numbers that results extraneous output. The else is incorrectly indented one tab too far to the right and is nested under (for x in range

[issue3490] Example Code Error in Tutorial Documentation

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks! Fixed in r65382. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue3491] compile error fixing (_multiprocessing, windows)

New submission from Hirokazu Yamamoto <[EMAIL PROTECTED]>: This will fix the compile error on buildbot. Thank you. -- components: Windows files: fix_compile_error.patch keywords: patch, patch messages: 70615 nosy: ocean-city severity: normal status: open title: compile error fixing (_mul

[issue3490] Example Code Error in Tutorial Documentation

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Sorry, the example actually is correct. (reverted) -- resolution: fixed -> rejected ___ Python tracker <[EMAIL PROTECTED]>

[issue3491] compile error fixing (_multiprocessing, windows)

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

[issue3480] Fix_imports pattern optimization

Collin Winter <[EMAIL PROTECTED]> added the comment: Committed as r65397. Nice work! -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3358] 2to3 Iterative Wildcard Matching

Collin Winter <[EMAIL PROTECTED]> added the comment: Nick, what do you think about that? ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bu

[issue3358] 2to3 Iterative Wildcard Matching

Nick Edds <[EMAIL PROTECTED]> added the comment: Sounds good to me. I should have a chance to implement this and submit it within the next couple of days. ___ Python tracker <[EMAIL PROTECTED]> ___