[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: This behavior is intentional - positional arguments must be sequential, not broken up with optional (flag) arguments between. So this is a documentation bug. Allowing positional arguments to be broken up with optional (flag) arguments between them would be a new feature. It would also break many current parsers, so it couldn't be turned on by default. A new constructor parameter or method or something would have to be added to ArgumentParser. Patches welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14200] Idle shell crash on printing non-BMP unicode character
Vlastimil Brom vlastimil.b...@gmail.com added the comment: Sorry for mixing the different problems, these were somehow things I noticed at once in the new python version, but I should have noticed the different domains myself. I still might not understand the term crash properly - I just meant to distinguish between a single appropriate exception on an invalid operation (while the app is staying alive and works on next valid input) - as is the case with calling through python.exe, and - on the other hand - the immediate termination on encountering the invalid input, which happens with pythonw.exe. Now I see, that with pythonw a tk app terminates with the first exception (in general) in py 3.3 and also 3.2 (as opposed to py 2.7, where it just swallows the exception and stays alive, as one would probably expect). Should this be reported in a separate issue, or is this what remains relevant in *this* report? (Sorry for the confusion.) vbr -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13183] pdb skips frames after hitting a breakpoint and running step
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14196] Unhandled exceptions in pdb return value display
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12913] Add a debugging howto
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10369] tarfile requires an actual file on disc; a file-like object is insufficient
Changes by Lars Gustäbel l...@gustaebel.de: -- resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10369 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: I had intended to wait until the code had been tested on all of the buildbots before closing it. However, it's taking a while to get xz-utils installed on the last few bots, so it doesn't make sense to keep the issue open for this. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] Support xz compression in tarfile module
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14206] multiprocessing.Queue documentation is lacking important details
sbt shibt...@gmail.com added the comment: What you were told on IRC was wrong. By default the queue *does* have infinite size. When a process puts an item on the queue for the first time, a background thread is started which is responsible for writing items to the underlying pipe. This does mean that, on exit, the process should wait for the background thread to flush all the data to the pipe. This happens automatically unless you specifically prevent it by calling cancel_join_thread() method. If you stick to those methods supported by standard queue objects, then things should work correctly. (Maybe cancel_join_thread() would be better named allow_exit_without_flush().) -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14181] Support getbuffer redirection scheme in memoryview
Stefan Krah stefan-use...@bytereef.org added the comment: Then I'm abusing this ticket to say: thanks for verifying this. I would still like to sweep this fact under the rug. :) Could you have a look at the documentation patch and see if it's clearer? -- keywords: +patch Added file: http://bugs.python.org/file24744/issue14181-doc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14006] Improve the documentation of xml.etree.ElementTree
Eli Bendersky eli...@gmail.com added the comment: BTW, the issue 6488 is still opened. I did not check if there's something left to do before to close it. The fundamental problem issue #6488 was opened for still exists - the docs use the term path without defining it. This should be addressed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14181] Support getbuffer redirection scheme in memoryview
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset da2aaced21bd by Stefan Krah in branch 'default': Issue #14181: Improve clarity in the documentation for the multi-purpose http://hg.python.org/cpython/rev/da2aaced21bd -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641544] rlcompleter tab completion in pdb
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1641544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14181] Support getbuffer redirection scheme in memoryview
Stefan Krah stefan-use...@bytereef.org added the comment: OK, for me the view-obj issues are done. The new tests indicate that we can silently keep backwards compatibility for view-obj==NULL, but I suppressed that fact in the documentation because it's already complicated enough. Perhaps we might want to deprecate (if one can deprecate an undocumented feature) view-obj==NULL at some point. Stefan, thanks for bringing all this up on python-dev! -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14208] No way to recover original argv with python -m
Changes by Éric Araujo mer...@netwok.org: -- nosy: +brett.cannon, eric.araujo, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13719] bdist_msi upload fails
Éric Araujo mer...@netwok.org added the comment: I’m working on this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages
New submission from James Pickering jamespi...@googlemail.com: If you run pkgutil.iter_zipimport_modules with a prefix parameter, and the module in question is a package, then the prefix parameter is ignored. The most visible symptom of this is when running pkgutil.walk_packages for a zipfile. Imagine we have a module structure like this (or create one): a/ a/__init__.py a/b/ a/b/__init.__py If we put this structure in a directory, add the directory to sys.path, and run pkgutil.walk_packages(), it will find modules a and a.b. If we put this structure in a zipfile, however, we add this file to sys.path, and run pkgutil.walk_packages(), it will find modules a and b. This is because pkgutil.iter_zipimport_modules ignores the prefix parameter a.. This is incorrect. This can be fixed by changing line ~344 of Lib/pkgutil.py from: yield fn[0], True to yield prefix + fn[0], True Thanks, James P.s, This is my first Python bug report. I apologise in advance for any poor etiquette. -- components: Library (Lib) messages: 155018 nosy: James.Pickering priority: normal severity: normal status: open title: pkgutil.iter_zipimport_modules ignores the prefix parameter for packages type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
guilherme-pg guilherme.p.g...@gmail.com added the comment: I uploaded an incomplete patch that might address the issue so it can be discussed. This patch introduces 'greedy_star', a new constructor parameter to ArgumentParser that makes * positional arguments behave as expected in the test case. The patch doesn't yet update the documentation and doesn't include test cases, but I'll be glad to provide those changes in a next version. It is admittedly hackish, but I haven't found a better solution so far. Looking forward for your comments. -- keywords: +patch nosy: +guilherme-pg Added file: http://bugs.python.org/file24745/14191.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14210] add filename completion to pdb
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: This would be extra nice because I would not have to fill in the entire path manually when I'm setting a b(reak). -- components: Library (Lib) messages: 155020 nosy: tshepang priority: normal severity: normal status: open title: add filename completion to pdb type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Jim Jewett jimjjew...@gmail.com added the comment: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure that they can't easily defend against. Would it be worth adding a counter to lookdict, so that one modification is OK, but 5 aren't? -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13860] PyBuffer_FillInfo() return value
Changes by Stefan Krah stefan-use...@bytereef.org: -- dependencies: -bytearray_getbuffer: unnecessary code resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - adapt sphinx-quickstart for windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13860] PyBuffer_FillInfo() return value
Changes by Stefan Krah stefan-use...@bytereef.org: -- superseder: adapt sphinx-quickstart for windows - bytearray_getbuffer: unnecessary code ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
STINNER Victor victor.stin...@gmail.com added the comment: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? The issue was triggered without threads.If the __eq__ method of the objects used for keys use C functions releasing the GIL, you may trigger the issue. Would it be worth adding a counter to lookdict, so that one modification is OK, but 5 aren't? If you implement a special type modifying the dict that contains the object, you should implement your own retry function on lookup failure (catch RuntimeError). Honestly, if you get RuntimeError, you should change your program, not retry the lookup! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Mark Shannon m...@hotpy.org added the comment: Jim Jewett wrote: Jim Jewett jimjjew...@gmail.com added the comment: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? So, they are writing to a dict in one thread while reading from the same dict in another thread, without any external locks and with keys written in Python. I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure that they can't easily defend against. I suspect, they are already seeing sporadic failures. I think raising an exception is better than weird failures. We should document the new behaviour, as it is a change in semantics. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
STINNER Victor victor.stin...@gmail.com added the comment: If the __eq__ method of the objects used for keys use C functions releasing the GIL, you may trigger the issue. Oh, I mean: trigger the issue with threads. I hope that your objects don't call C functions like open() in their __eq__() method! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()
New submission from STINNER Victor victor.stin...@gmail.com: PyObject_GenericSetAttr() doesn't keep a reference to the descriptor: Python does crash if the descriptor is destroyed while the attribute is set. Attached patch keeps a reference to the desriptor to avoid the crash. A smililar was done in PyObject_GenericGetAttr() 8 years with the changelog fix obscure crash in descriptor handling, see the changeset 941d49a65f06. The patch fixes Lib/test/crashers/borrowed_ref_2.py and so removes it. -- files: type_lookup_ref.patch keywords: patch messages: 155025 nosy: haypo priority: normal severity: normal status: open title: Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr() Added file: http://bugs.python.org/file24746/type_lookup_ref.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14211 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()
Changes by STINNER Victor victor.stin...@gmail.com: -- type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14211 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()
Changes by STINNER Victor victor.stin...@gmail.com: -- components: +Interpreter Core versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14211 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Guido van Rossum gu...@python.org added the comment: On Tue, Mar 6, 2012 at 8:56 AM, Mark Shannon rep...@bugs.python.org wrote: Mark Shannon m...@hotpy.org added the comment: Jim Jewett wrote: Jim Jewett jimjjew...@gmail.com added the comment: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? So, they are writing to a dict in one thread while reading from the same dict in another thread, without any external locks and with keys written in Python. I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure that they can't easily defend against. I suspect, they are already seeing sporadic failures. I think raising an exception is better than weird failures. We should document the new behaviour, as it is a change in semantics. +1 on everything you said. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Jim Jewett jimjjew...@gmail.com added the comment: On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote: Jim Jewett: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? So, they are writing to a dict in one thread while reading from the same dict in another thread, without any external locks and with keys written in Python. Correct. For example, it could be a configuration manager, or a cache, or even a worklist. If they're just adding new keys, or even deleting other (== NOT the one being looked up) keys, why should that keep them from finding the existing, unchanged keys? I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure that they can't easily defend against. I suspect, they are already seeing sporadic failures. How? The chain terminates as soon as the dict doesn't resize; without malicious intent, the odds of hitting several resizes in a row are so miniscule that it probably hasn't even slowed them down. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14212] Segfault when using re.finditer over mmap
New submission from Maciej Fijalkowski fij...@gmail.com: Example to get a segfault attached. Crashes under python3 as well. -- files: x.py messages: 155028 nosy: fijall priority: normal severity: normal status: open title: Segfault when using re.finditer over mmap type: crash versions: Python 2.7 Added file: http://bugs.python.org/file24747/x.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Guido van Rossum gu...@python.org added the comment: On Tue, Mar 6, 2012 at 9:43 AM, Jim Jewett rep...@bugs.python.org wrote: Jim Jewett jimjjew...@gmail.com added the comment: On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote: Jim Jewett: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? So, they are writing to a dict in one thread while reading from the same dict in another thread, without any external locks and with keys written in Python. Correct. For example, it could be a configuration manager, or a cache, or even a worklist. If they're just adding new keys, or even deleting other (== NOT the one being looked up) keys, why should that keep them from finding the existing, unchanged keys? Use a lock or a built-in key class. I realize that neither is ideal, but then, neither was the old situation. I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure that they can't easily defend against. I suspect, they are already seeing sporadic failures. How? The chain terminates as soon as the dict doesn't resize; without malicious intent, the odds of hitting several resizes in a row are so miniscule that it probably hasn't even slowed them down. Now I'm torn. If we'd have this RuntimeError from the start, would we consider it a flaw in the dict implementation or a feature? The RuntimeError when changing a dict's size while iterating over it is definitely a feature (so as to allow the implementation to rehash everything upon insert/delete). But this is not quite the same. Or is it? On the one hand I think the scenario is pretty unlikely (mostly because it involves a user-defined comparison); OTOH it would be quite nasty to debug. Or would it? You do get a decent error message... Note that Victor's alternate fix (nomodify.diff) has the same problem -- it just raises RuntimeError in the mutating thread rather than in the lookup thread. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14213] python33.dll not removed on uninstallation
New submission from Vinay Sajip vinay_sa...@yahoo.co.uk: I built an MSI for Python 3.3 on Windows 7 and installed from it - the resulting installation seems to work OK in that it passes all tests except test_tcl (intermittent failure). However, when I uninstall, python33.dll is left behind in System32. If I rebuild Python and the MSI after some changes and reinstall, the old python33.dll is not overwritten with the new one. -- components: Installation, Windows messages: 155030 nosy: loewis, vinay.sajip priority: normal severity: normal status: open title: python33.dll not removed on uninstallation type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Jim Jewett jimjjew...@gmail.com added the comment: (1) I think this module would benefit greatly from a map explaining what each file does, and perhaps from some reorganization. As best I can yet tell, there are about ~130 files, over a dozen directories, but the only ones that directly affect the implementation are a subset (~33) of the *.c and *h files in Modules/_decimal/ (and not subdirectories). Even files that do affect the implementation, such as mpdecimal.c, also seem to have functions thrown in just for testing small pieces of functionality, such as Newton Division. There may also be some code that really isn't needed, except possibly for backwards compatibility, and could be #ifdef'ed or at least commented. For example, the comments above io.c function _mpd_strneq(const char *s, const char *l, const char *u, size_t n) mention working around the Turkish un/dotted-i problem when lowercasing -- but why is a decimal library even worried about casing? (2) Is assembly allowed? If not, please make it clear that vcdiv64.asm is just an optional speedup, and that the code doesn't rely upon it. (3) Are there parts of this library that provide functionality NOT in the current decimal library? If so, this should be at least documented, and perhaps either removed or exposed. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14200] Idle shell crash on printing non-BMP unicode character
Martin v. Löwis mar...@v.loewis.de added the comment: That pythonw suddenly closes is a separate issue: if pythonw attempts to write to stderr, it crashes. To get your example to run in pythonw.exe, try pythonw.exe Lib\idlelib\idle.py 2 out.txt I think the behavior of pythonw terminating when it can't write to stderr is actually correct: an exception is raised on attempting to write to stderr, which then can be printed (because there is no stderr). So the real fault here is the traceback that python.exe reports. To fix this, I think rpc.py should learn to marshal exceptions back to the subprocess. Then the initial sys.stdout.write should raise a UnicodeError (which it currently doesn't, either). This would get into the displayhook, which would then run use sys_displayhook_unencodable to backslashescape the unsupported character. I'll attach a patch that at least makes the exception UnicodeEncodeError. -- keywords: +patch Added file: http://bugs.python.org/file24748/unicodeerror.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14212] Segfault when using re.finditer over mmap
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: It segfaults because it attempts to access the buffer of an mmap that has been closed. It would be certainly be more friendly if it checked whether the mmap was still open and, if not, raised an exception instead. -- nosy: +mrabarnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Jim, thanks for taking a look at this. Jim Jewett rep...@bugs.python.org wrote: (1) I think this module would benefit greatly from a map explaining what each file does, and perhaps from some reorganization. Just MAP.txt in the top level directory? Amaury suggested moving the library into a subdirectory. I'm not sure about that. The library would be out of sight, but is that a good thing? As best I can yet tell, there are about ~130 files, over a dozen directories, but the only ones that directly affect the implementation are a subset (~33) of the *.c and *h files in Modules/_decimal/ (and not subdirectories). Indeed the top level directory contains _decimal.c and all files from libmpdec. Almost all files are required. The three subdirectories contain: tests/ - library tests python/ - extended module tests literature/ - pointers to papers and explanations for trickier algorithms. Even files that do affect the implementation, such as mpdecimal.c, also seem to have functions thrown in just for testing small pieces of functionality, such as Newton Division. That is correct. They were deliberately added in that place because they rely on a couple of inline functions and I have a policy of testing the exact code that the original function relies on. The alternative is to extract all functions needed, move them to the test directory and hope that the code doesn't get stale. But if you have a better idea, I'd be glad to hear it: I don't like the test functions in that place either. The reason that Newton Division is tested for ridiculously small precisions like prec=1 is that it should pass IBM's test suite just like the regular division function. (Also, small precisions are most likely to expose problems). There may also be some code that really isn't needed, except possibly for backwards compatibility, and could be #ifdef'ed or at least commented. I'm not aware of any except for whole files: mpsignal.c - signaling wrappers for the mpdecimal.c functions, not needed for _decimal.c but part of libmpdec. mptest.h- header for running the tests. bench.c - library benchmark. Turkish un/dotted-i problem when lowercasing -- but why is a decimal library even worried about casing? Infinity, InFinItY, iNF are all allowed by the specification. (2) Is assembly allowed? I was under the assumption that it is allowed: Python/pymath.c:23:__asm__ __volatile__ (fnstcw %0 : =m (cw)); Python/pymath.c:28:__asm__ __volatile__ (fldcw %0 : : m (cw)); Python/ceval.c:43:asm volatile (mftbu %0 : =r (tbu) ); Python/ceval.c:44:asm volatile (mftb %0 : =r (tb) ); Python/ceval.c:45:asm volatile (mftbu %0 : =r (tbu2)); Python/ceval.c:59: __asm__ __volatile__(rdtsc : =A (val)) Python/ceval.c:69:__asm__ __volatile__(rdtsc : \ If not, please make it clear that vcdiv64.asm is just an optional speedup, and that the code doesn't rely upon it. No code relies on asm. Assembly is only used for the double word mul/divmod primitives in typearith.h and the Pentium PRO modular multiplication in umodarith.h, and there are ANSI versions for everything. The library really compiles with any compiler I have tested, including compilers without uint64_t like CompCert (CompCert does not compile Python for example, but for other reasons). (3) Are there parts of this library that provide functionality NOT in the current decimal library? If so, this should be at least documented, and perhaps either removed or exposed. Apart from mpsignal.c (see above), there are probably a couple of things in the header files like mpd_invroot(). _mpd_qinvroot() from mpdecimal.c *is* needed because the square root is calculated in terms of the inverse square root. Are these (probably) minor instances of additional functionality a big problem for you? Because for me it would be a hassle to maintain diverging versions of libmpdec and the Python version of libmpdec. This is also related to testing: The complete test suite (all tests against decNumber and decimal.py) under Valgrind takes 8 months to run. My question is: Where should I document these things and in what detail? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14158] test_mailbox fails if file or dir named by support.TESTFN exists
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 1112c2f602b3 by Vinay Sajip in branch '2.7': Closes #14158: We now track test_support.TESTFN cleanup, and test_mailbox uses shutil.rmtree for simpler code. http://hg.python.org/cpython/rev/1112c2f602b3 -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: STINNER Victor rep...@bugs.python.org wrote: How can I help to integrate this module into CPython? It would be fantastic if you could take a look at _decimal.c, for example to find some incompatibilities between _decimal.c and decimal.py. mpdecimal.c could also always profit from another audit. That's the only file that still needs to go through my second self-audit round. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14205] Raise an error if a dict is modified during a lookup
Jim Jewett jimjjew...@gmail.com added the comment:
On Tue, Mar 6, 2012 at 1:05 PM, Guido van Rossum
Jim Jewett:
... If they're just adding new keys, or even deleting other
(== NOT the one being looked up) keys, why should that
keep them from finding the existing, unchanged keys?
... The chain terminates as soon as the dict doesn't resize; without
malicious intent, the odds of hitting several resizes in a row are so
miniscule that it probably hasn't even slowed them down.
Now I'm torn. If we'd have this RuntimeError from the start, would we
consider it a flaw in the dict implementation or a feature?
I would personally have considered it a flaw. Wrapping all dict
access just in case some other code added a weird key seems ugly and
inefficient.
RuntimeError when changing a dict's size while iterating over it is
definitely a feature (so as to allow the implementation to rehash
everything upon insert/delete).
In that case, you've explicitly asked for the whole set (or at least a
snapshot); the RuntimeError indicates that you can't get it. Maybe
there should be a way to say I don't need the set to be perfect, but
there isn't, and you aren't getting what you actually did ask for, so
an Error is appropriate.
But in this case, you're asking for a specific key, and the key is
there. It may even be a perfectly normal string, that just happened
to hash-collide with something some other code inserted.
The RuntimeError exposes a race condition to user code -- and it may
not be the code that stuck the oddball class in the dict in the first
place.
Note that Victor's alternate fix (nomodify.diff) has the same problem
-- it just raises RuntimeError in the mutating thread rather than in
the lookup thread.
Right; I'm saying that raising an error is the wrong thing to do.
But there is an analogy to the hash-code change vs collision counting.
Breaking an application that got unlucky once is wrong. But if the
bad luck *continues* to the point where it would only occur one time
in a zillion, RuntimeError is better than a likely infinite loop.
(It really was a question initially, but I've now convinced at least myself.)
I would rather see something like replacing
349 else {
350 /* The compare did major nasty stuff to the
351 * dict: start over.
352 * XXX A clever adversary could prevent this
353 * XXX from terminating.
354 */
355 return lookdict(mp, key, hash);
with
349 else {
350 /* The compare did major nasty stuff to the
351 * dict: start over.
352 * XXX A clever adversary could prevent this
353 * XXX from terminating.
354 */
355 return lookdict_paranoid(mp, key, hash, 1);
where lookdict_paranoid is a near-copy of lookdict that adds a
paranoia parameter and replaces those same lines with
else {
/* The compare did major nasty stuff *again*. */
if (paranoia PARANOIA_LEVEL) {
return lookdict_paranoid(mp, key, hash, paranoia+1);
}
/* Something is wrong; raise a RuntimeError. */
}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14205
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14213] python33.dll not removed on uninstallation
Martin v. Löwis mar...@v.loewis.de added the comment: I guess this is a misconfiguration for your system. This DLL is reference-counted, and you must have arranged the reference count to be 1 somehow. Inspect the MSI log for details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Interesting that the behavior is intentional, yet it accepts positional parameters either before, or after, or between optional (flag) parameters. This seems to me to be a case where proper documentation of the intention would have led to the realization that it is easier to fix the code than the documentation. The only definition of positional parameters I could find in the present documentation is: When parse_args() is called, optional arguments will be identified by the - prefix, and the remaining arguments will be assumed to be positional: This is simple and succinct, but leads to my interpretation that they can be anywhere, intermixed with optional arguments. Further, optparse, which argparse attempts to replace, permitted positional arguments to be intermixed with optional arguments, see new file t13.py which demonstrates that. To document that positional parameters must be grouped together, yet can appear anywhere, the documentation would have to get much more verbose... something like All positional parameters must be grouped together in a single sequence. However, that group of parameters may have optional parameters either before it or after it, or there may be optional parameter both before it and after it. -- Added file: http://bugs.python.org/file24749/t13.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14213] python33.dll not removed on uninstallation
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Yes, the refcount was 1 after uninstallation - possibly it's been like that for a long time. I'll close the issue, but one thing occurs to me - isn't the DLL's version resource updated when you rebuild? Why wouldn't the newer version in an MSI being installed overwrite the older one in Windows\System32? -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14213] python33.dll not removed on uninstallation
Martin v. Löwis mar...@v.loewis.de added the comment: The version number is not changed on every rebuild, only when patchlevel.h changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14202] The docs of xml.dom.pulldom are almost nonexistent
Florian M florian.mladit...@googlemail.com added the comment: I wrote some documentation with the information I found on http://wiki.python.org/moin/PullDom and some custom examples. -- nosy: +flomm Added file: http://bugs.python.org/file24750/xml.dom.pulldom.rst ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14208] No way to recover original argv with python -m
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14214] test_concurrent_futures hangs
New submission from Miki Tebeka miki.teb...@gmail.com: Running make test on 3.3a source tree on Ubuntu 11.10 (64bit) hangs at test_concurrent_futures -- components: Tests messages: 155043 nosy: tebeka priority: normal severity: normal status: open title: test_concurrent_futures hangs versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14214 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14208] No way to recover original argv with python -m
Nick Coghlan ncogh...@gmail.com added the comment:
This is closely related to PEP 395, since multiprocessing currently hits the
same issue in trying to figure out the correct setting for sys.argv0.
I quite like the sys.__argv__ idea for preserving the *exact* underlying
command line (Alex Gaynor was recently asking for something similar to this).
In the meantime, it should be possible to work around the problem by running
the affected subprocess invocations (i.e. when __main__.__package__ exists and
is not empty) with something like:
launch_template =
import runpy, sys
sys.argv[:] = {argv}
sys.path[:] = {path}
runpy._run_module_as_main({main})
import sys, subprocess, os.path, __main__
main_base = os.path.basename(__main.__file__).splitext()[0]
main_ref = __main__.__package__ + . + main_base
launch = launch_template.format(argv=sys.argv, path=sys.path, main=main_ref)
subprocess.call(launch, shell=True, executable=sys.executable)
Note: the above isn't tested code, since it's an approach that only occurred to
me recently and I haven't had a chance to fully explore it myself. However, if
it works, we could make use of it in 2.7 and 3.2 to fix multiprocessing's
current misbehaviour on Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14208
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Benjamin Peterson benja...@python.org added the comment: The scripts for generating code would preferably go in a Tools/decimal directory. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Jim Jewett jimjjew...@gmail.com added the comment:
On Tue, Mar 6, 2012 at 3:07 PM, Stefan Krah
Jim Jewett rep...@bugs.python.org wrote:
(1) I think this module would benefit greatly from a map explaining
what each file does, and perhaps from some reorganization.
Just MAP.txt in the top level directory?
That should work. There may be better names, but I can't think of any just now.
Amaury suggested moving
the library into a subdirectory. I'm not sure about that. The
library would be out of sight, but is that a good thing?
cdecimal certainly needs a subdirectory similar to those for _io,
_ctypes, _multiprocessing, and _sqlite.
It *may* make sense to move some of the subdirectories around. (On
the other hand, it may not; if the tests in Lib/test/ end up
delegating back, that is probably OK.)
I believe it would be helpful to move non-code (project files, etc) to
separate directories.
Whether you need *additional* subdirectories within _cdecimal to
subcategorize the .c and .h files, I'm not sure -- because I didn't
get in deep enough to know what they should be. If the categorization
let people focus on the core, that would be helpful, but it wasn't
clear to me which files were part of the exported API and which were
implementation details. Are there are clear distinctions (type
info/python bindings/basic arithmetic/advanced
algorithms/internal-use-only/???)
As best I can yet tell, there are about ~130 files, over a dozen directories,
but the only ones that directly affect the implementation are a subset (~33)
of the *.c and *h files in Modules/_decimal/ (and not subdirectories).
Indeed the top level directory contains _decimal.c and all files
from libmpdec. Almost all files are required.
Would it make sense to integrate only cdecimal, and to treat libmpdec
as an external dependency that (usually) gets updated with each Python
feature release, the way that sqlite is?
The three subdirectories contain:
tests/ - library tests
python/ - extended module tests
I would really expect that to still be under tests, and I would expect
a directory called python to contain code written in python, or at
least python bindings.
literature/ - pointers to papers and explanations for trickier algorithms.
Even files that do affect the implementation, such as mpdecimal.c,
also seem to have functions thrown in just for testing small pieces
of functionality, such as Newton Division.
That is correct. They were deliberately added in that place because they rely
on a couple of inline functions and I have a policy of testing the exact code
that the original function relies on.
How important is it that these functions be inline?
Would it at least be OK to wrap them in stubs for exporting, so that
the test logic could be places with the others tests? (I worry that
some tests may stop getting run if someone else modifies the build
process and doesn't notice the unusual location.)
The alternative is to extract all functions needed, move them to the test
directory and hope that the code doesn't get stale.
I agree that copying is bad.
I'll trust your judgement on the need for inline. But given:
ALWAYS_INLINE int
mpd_word_digits(mpd_uint_t word)
I don't see anything wrong with exporting:
int
_testhelp_mpd_word_digits(mpd_uint_t word) {
return mpd_word_digits(word);
}
Turkish un/dotted-i problem when lowercasing -- but why is a decimal
library even worried about casing?
Infinity, InFinItY, iNF are all allowed by the specification.
OK; so is io.c part of the library, or part of the python binding?
Given that this is targeted at 3.3 or later, would it make sense to
either use casefolding, or check the kind? (If it isn't ASCII, it
can't be the word INF.)
Are there only a certain number of strings that will ever matter, such
as INF, NAN, and INFINITY, so that a case statement would work?
tolower() with an extra check for the turkish undotted lower case i?
What you have may well be the best compromise, but it bothers me to
see text processing tools redone in a numeric type -- particularly
without knowing why they are needed.
(2) Is assembly allowed?
I was under the assumption that it is allowed:
I'm honestly not sure, but I think that was one of the reasons
stackless was never integrated.
If not, please make it clear that vcdiv64.asm is just an optional speedup,
and that the code doesn't rely upon it.
No code relies on asm. Assembly is only used for the double word mul/divmod
primitives in typearith.h and the Pentium PRO modular multiplication in
umodarith.h, and there are ANSI versions for everything.
Good enough, though I would rather see that as a comment near the assembly.
(3) Are there parts of this library that provide functionality NOT
in the current decimal library? If so, this should be at least
documented, and perhaps either removed or exposed.
Apart from mpsignal.c (see above), there are
[issue7652] Merge C version of decimal into py3k.
Benjamin Peterson benja...@python.org added the comment: Speaking of inline, the inline keyword will have to go because it's not C89. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14202] The docs of xml.dom.pulldom are almost nonexistent
Eli Bendersky eli...@gmail.com added the comment: Thanks, Florian - I will review the patch. At first sight it looks much better than what exists. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate
Jim Jewett jimjjew...@gmail.com added the comment: I think the latest patch is indeed cleaner. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Ramchandra Apte maniandra...@gmail.com added the comment: But we could check if the compiler supports the inline keyword and use it if available. -- nosy: +ramchandra.apte ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14215] http://www.python.org/dev/peps/ title is python.org
New submission from Ramchandra Apte maniandra...@gmail.com: The http://www.python.org/dev/peps browser title is python.org I suggest it should be changed to PEP Index. -- messages: 155051 nosy: ramchandra.apte priority: normal severity: normal status: open title: http://www.python.org/dev/peps/ title is python.org type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole nicholas.c...@gmail.com added the comment: I hope that this is the right bug to file this on (I'm getting lost in all of the curses bugs!). I'm testing out the 3.3a1, and I've run into the following issue. On previous releases addch() could accept curses.ACS_HLINE and similar. Attempting to use the same code now raises the exception: OverflowError: byte doesn't fit in chtype. I'm sure this is related to the new code that uses addwstr(), but currently code that used to work will crash. I can't work out a fix myself, because I don't fully understand the problem, but I'm happy to provide sample code if it will help. Nicholas -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14208] No way to recover original argv with python -m
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Instead of sys.__argv__, may I suggest sys.argv_original or somesuch. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
R. David Murray rdmur...@bitdance.com added the comment: Since this bug is about adding a new feature, it is unlikely to be the correct bug for this to be against. Given that you've identified a regression, I suggest you open a new bug with a reproducer, and we'll set it to release blocker. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14216] ImportError: No module named binascii
New submission from Qian Liu liuq0...@e.ntu.edu.sg: File ~/PythonInstall/lib/python2.7/multiprocessing/process.py, line 129, in start from .forking import Popen File ~/PythonInstall/lib/python2.7/multiprocessing/forking.py, line 58, in module from pickle import Pickler File ~/PythonInstall/lib/python2.7/pickle.py, line 1266, in module import binascii as _binascii ImportError: No module named binascii The used OS is: [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2 NOTED: There is no error when I import binascii in Python 2.7.2 on Window XP. How to solve it? Many thanks. -- components: Library (Lib) messages: 155055 nosy: liuqianhn priority: normal severity: normal status: open title: ImportError: No module named binascii type: crash versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
