[issue15494] Move test/support.py into a test.support subpackage
Martin v. Löwis added the comment: -1. test.support is not at all too large for a single module; there is no point in refactoring it. Without a specific patch to review which proposes some specific change, I'm rejecting this change request. -- nosy: +loewis resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
Catherine Devlin added the comment: Needed to update the patch slightly for Python 3; now that filter() returns an iterator, ``do_help``'s call to names = self.get_names() followed by names.sort() was throwing an error, so I changed get_names to return a list. -- nosy: +Catherine.Devlin Added file: http://bugs.python.org/file26593/python-cmd-better-filtering-py3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13214 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15489] Correct __sizeof__ support for BytesIO
Serhiy Storchaka added the comment:
Antoine, it looks like you committed the wrong patch for 3.3. Patches for 3.2
and 3.3 are different, otherwise I would have provided a one patch.
-basesize = support.calcobjsize('P2PP2PP')
+basesize = support.calcobjsize('P2nN2Pn')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15489
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
Catherine Devlin added the comment: Change to test_cmd.py to test for help displaying the name of the registered subcommand (as well as a simple test for the basic operation of the registered sub-CLI). -- Added file: http://bugs.python.org/file26594/test_cmd.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13214 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15496] harden directory removal for tests on Windows
Tim Golden added the comment: This is a (near) duplicate of issue7443, I think. -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c
New submission from Ned Deily: getpath.c uses three OS X APIs that have been producing deprecation warnings since at least OS X 10.5: NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule. We should figure out how to live without them. -- assignee: ronaldoussoren components: Macintosh messages: 166863 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Eliminate the use of deprecated OS X APIs in getpath.c versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Nick Coghlan added the comment: Martin, this change has been specifically requested by me to better organise all the support code that ISN'T in test.support. That file is already huge, and I'm not going to make it even bigger with all the test infrastructure needed for generating packaging heirarchies and zip files and invoking Python subprocesses in various ways. However, that support code *does* need to be made more discoverable (so we stop reinventing these wheels badly). A package with the current support.py as its __init__.py is the obvious solution. -- resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Serhiy Storchaka added the comment:
For the PyAccu, AFAICT, objects cannot leak out of it (except for
gc.getobjects in debug mode).
Not only in debug mode.
import io, gc
s=io.StringIO()
s.write('12345')
5
s.write('qwerty')
6
for o in gc.get_objects():
... if '123 in repr(o) and len(repr(o)) 1000:
... print(type(o), repr(o))
...
class 'list' ['12345', 'qwerty']
class 'list' ['o', 'gc', 'get_objects', 'repr', 'o', '123, 1000, 'len',
'repr', 'o', 'print', 'type', 'o', 'repr', 'o']
class 'tuple' ('123, 1000, None)
Someone can summarize sys.getsizeof() for all managed by GC objects and
therefore count internal objects twice.
I think the standard library should provide a method for recursive calculation
of memory (in some sense, perhaps using different strategies), but that should
wait up to 3.4. __sizeof__ should count non-object memory that is not available
for GC. As I understand it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15495] enable type truncation warnings for gcc builds
Mark Dickinson added the comment: How many extra warnings do you get by adding these flags (e.g., just by doing 'export CFLAGS= ...' before building)? It might be useful to see a sampling of those warnings. The addition of these flags should be conditional on gcc's version being = 4.3: gcc 4.2 apparently has a different meaning for -Wconversion (to do with implicit conversions when passing function arguments), and generates crazy numbers of warnings on my OS X 10.6 machine (which comes with gcc 4.2). Why '-Wno-sign-conversion'? Is fixing all the places that have implicit sign conversions a reasonable goal, or are there just too many of those? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15495 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15267] tempfile.TemporaryFile and httplib incompatibility
Atsuo Ishimoto added the comment: patch contains fix and test for 2.7. With this patch, AttibuteError is captured as Tim sujested. -- keywords: +patch nosy: +ishimoto Added file: http://bugs.python.org/file26595/issue15267.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Martin v. Löwis added the comment: For the PyAccu, AFAICT, objects cannot leak out of it (except for gc.getobjects in debug mode). Not only in debug mode. I see. I meant sys.getobjects, which is in debug mode only, but I now see that gc.get_objects will get the list (but not the strings) of the Accu. That still leaves readnl and writenl. I think the standard library should provide a method for recursive calculation of memory (in some sense, perhaps using different strategies), but that should wait up to 3.4. Actually, this is (and should be) a separate project: http://guppy-pe.sourceforge.net/ __sizeof__ should count non-object memory that is not available for GC. As I understand it. I think you misunderstand slightly; the GC relevance is only a side effect. __sizeof__ should only account for memory that isn't separately accessible. The notion of separately accessible is somewhat weak, since it may depend on the container. Non-PyObject blocks clearly need to be accounted for. PyObject blocks normally don't need to be accounted for, as they are typically accessible separately, by the following means: - gc.get_objects (for GC objects) - gc.get_referents (for contained non-GC objects) There are also irregular ways to get objects: - in debug mode only: sys.getobjects - customer access functions or attributes For memory accounting, it would really be best if the latter two categories wouldn't exist, i.e. if all non-GC objects were still visible through tp_traverse. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6
Roundup Robot added the comment: New changeset f96579debefa by Ned Deily in branch 'default': Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs. http://hg.python.org/cpython/rev/f96579debefa -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15470] Stuck/hang when reading ssl object
Seamus McKenna added the comment: Thankyou for update. Script was not using 100% cpu. I will add SMTP timeout and increase debuglevel() within the function should this reoccur. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Martin v. Löwis added the comment: So who is going to provide a patch for it, and when? I don't think the tracker is the right place to keep list of things that someone wants to do some day. There isn't an issue Python should have a JIT, either. Tracker issues should be actionable at the time the issue is submitted, unless there is a clear criterion on which to defer the issue. If the objective is to just put the module into an __init__.py, it takes just a few minutes, no? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Nick Coghlan added the comment: As noted in the original post, this is a change which will be made once the 3.3 release is out the door. It's origin lies in the fact that one of the new pkgutil tests currently lives in test_runpy because test_runpy has much better infrastructure for that kind of thing. While figuring out where to put some shared infrastructure for the runpy, pkgutil, import and importlib tests, I came to the conclusion that having support.py, script_helper.py and whatever we decide to call the new module all living in the main test directory makes the support modules unnecessarily hard to find, and merging them all into a single massive support.py module doesn't make sense either. Chris has been working on the patches. We were going to try to get this refactoring done before the release, but enough other things have ended up coming up that Antoine and I decided it was better to wait. -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15403] Refactor package creation support code into a common location
Changes by Nick Coghlan ncogh...@gmail.com: -- dependencies: +Move test/support.py into a test.support subpackage ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15403 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15376] Refactor the test_runpy walk_package support code into a common location
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15376 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15376] Refactor the test_runpy walk_package support code into a common location
Changes by Nick Coghlan ncogh...@gmail.com: -- dependencies: +Add temp_dir() and change_cwd() to test.support ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15376 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Nick Coghlan added the comment: I've just gone through and made sure all the related issues are correctly assigned to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6
Roundup Robot added the comment: New changeset 7232d544c811 by Ned Deily in branch '2.7': Issue #14018: Update the OS X IDLE Tcl/Tk warning check to include http://hg.python.org/cpython/rev/7232d544c811 New changeset 17ddc0c34d9d by Ned Deily in branch '3.2': Issue #14018: Update the OS X IDLE Tcl/Tk warning check to include http://hg.python.org/cpython/rev/17ddc0c34d9d New changeset 28cb0bcaa22e by Ned Deily in branch 'default': Issue #14018: merge http://hg.python.org/cpython/rev/28cb0bcaa22e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Changes by Martin v. Löwis mar...@v.loewis.de: -- versions: -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Changes by Martin v. Löwis mar...@v.loewis.de: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15486] Standardised mechanism for stripping importlib frames from tracebacks
Nick Coghlan added the comment: OK, after a bit of experimentation, it appears both 3.2 and 3.3 eventually get annoyed if you mess about too much with __pycache__. 1. They're both fine if __pycache__ is entirely unwritable (they just silently skip caching the bytecode) 2. 3.2 throws EOFError if you replace the cache entry with an empty file, 3.3 silently rewrites it with a valid cached version 3. 3.2 throws EOFError if you replace the cache entry with a directory, 3.3 throws a more accurate IsADirectory error That means my chosen test case is a valid one, and I can just update the offending call in importlib._bootrap to use the new frame stripping hook as I originally planned. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Roundup Robot added the comment: New changeset ff7fc6a91212 by Victor Stinner in branch 'default': Issue #15463: the faulthandler module truncates strings to 500 characters, http://hg.python.org/cpython/rev/ff7fc6a91212 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14966] Fully document subprocess.CalledProcessError
Changes by Anton Barkovsky swarmer...@gmail.com: -- nosy: +anton.barkovsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15499] Sleep is hardcoded in webbrowser.UnixBrowser
New submission from Anton Barkovsky: webbrowser.UnixBrowser._invoke will sleep for at least 1 second after launching browser process and then probably 4 more seconds. These numbers are hardcoded and can't be modified which is especially problematic for testing. I think this code should be replaced with Popen.wait with timeout. A patch is attached. -- components: Library (Lib) files: webbrowser_sleep.patch keywords: patch messages: 166877 nosy: anton.barkovsky priority: normal severity: normal status: open title: Sleep is hardcoded in webbrowser.UnixBrowser type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26596/webbrowser_sleep.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor added the comment: Issue #15463: the faulthandler module truncates strings to 500 characters, It should be able for most setup. See the issue #15479 if you consider that something better should be implemented. Long path names are handled differently on each platform, I don't want to add a test checking a path longer than 500 characters. You might add a new test for truncated path if limits become configurable (#15479). I consider this issue as resolved. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6
Roundup Robot added the comment: New changeset e0eb7dea245f by Ned Deily in branch '2.7': Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs. http://hg.python.org/cpython/rev/e0eb7dea245f New changeset eb0af7f6ea6d by Ned Deily in branch '3.2': Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs. http://hg.python.org/cpython/rev/eb0af7f6ea6d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15486] Standardised mechanism for stripping importlib frames from tracebacks
Nick Coghlan added the comment: Looking at the actual code - I don't think it actually makes sense to strip the frames in this case. Unlike the previous examples, it only comes up if someone is doing something deliberately pathological, at which point a little noise in the traceback is the least of your worries. Updated patch just drops that test case entirely and only has the changes that simplify the frame removal code. Since Georg isn't on IRC right now, assigning him to decide if he wants this version in beta 2 rather than the current multiple exit points approach. -- assignee: - georg.brandl Added file: http://bugs.python.org/file26597/issue15486_simplify_importlib_frame_removal_no_new_test.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15486] Standardised mechanism for stripping importlib frames from tracebacks
Changes by Nick Coghlan ncogh...@gmail.com: Removed file: http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: Shouldn't a test be added to check that the issue has been fixed though (i.e. a test with a path longer than the original 100 characters)? I provided a patch to show how this can easily be done. I would be happy to write the test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6
Ned Deily added the comment: The SDK test in setup.py has been extended to include files in /Library/Frameworks (see OS X ld man page). The test in IDLE to issue a warning message about unstable Tcl/Tk versions was updated to include the Apple-supplied Tcl/Tk 8.5 in OS X 10.7 and 10.8. All of these are applied for release in 2.7.4, 3.2.4, and 3.3.0. In addition for 3.3.0, checks are added to the OS X installer build script to ensure that the desired Tcl/Tk shared library has actually been linked as expected. (I plan to backport all outstanding build script changes prior to the 2.7.4 and 3.2.4 releases.) -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor added the comment: I provided a patch to show how this can easily be done. Your patch does not create a path longer than 100 characters. I didn't want to write such test, but I can review a patch adding such test. The limit is not only applied on the filename, but also on the function name. It is maybe easier (more portable) to declare a function with a very long name: exec(compile(def + f*600 + (): raise ValueError()\n + f*600 + (), a, exec)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Ned Deily added the comment: BTW, the applied patch does fix the problem originally reported. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: I didn't want to write such test, but I can review a patch adding such test. Thank you. I will provide a patch for your review. I think a test for the path may be better as that was the original issue experienced. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15489] Correct __sizeof__ support for BytesIO
Antoine Pitrou added the comment: Ah, but the BytesIO structure is the same in 3.2 and 3.3. Ok, that's because struct now has support for size_t and Py_ssize_t, I see. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15489] Correct __sizeof__ support for BytesIO
Roundup Robot added the comment: New changeset e77c117ab024 by Antoine Pitrou in branch 'default': Better test for BytesIO.__sizeof__, now that the struct module supports (s)size_t. http://hg.python.org/cpython/rev/e77c117ab024 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Antoine Pitrou added the comment: For some reason the new tests fail on the XP buildbots. -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15495] enable type truncation warnings for gcc builds
Christian Heimes added the comment: I'm getting more than thousand warnings: $ CFLAGS=-Wconversion -Wno-sign-conversion ./configure $ LC_ALL=C make -s -j8 21 | tee log $ grep Wconversion log | wc -l 1163 platform: Ubuntu 12.04 x86_64 gcc: 4.6.3 -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15495 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
New submission from Attila Nagy: Python class Thread has a name argument, which sets the name of the given thread. This name is used only internally, while there is a possibility to set this on an OS-level. Related discussion: http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux #include pthread.h int pthread_setname_np(pthread_t thread, const char *name); // FreeBSD OpenBSD: function name is slightly different void pthread_set_name_np(pthread_t tid, const char *name); // Mac OS X: it only seems applicable to the current thread (no thread ID) int pthread_setname_np(const char*); It would be very useful if Python set the name parameter with the above pthread calls, so the user/developer could see which threads do what in ps or top. -- components: Library (Lib) messages: 166890 nosy: bra priority: normal severity: normal status: open title: Python should support naming threads type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Christian Heimes added the comment: Right now major parts of the buffer API are broken for non-trivial buffer definitions. IMHO a backport of the fix doesn't count as a new feature although it needs some new internal functions. I don't quite understand why Nick thinks that ABI compatibility is a challenge. The structs, typedefs and function definitions aren't modified. The new functions aren't visible because they can be implemented as static functions if PyBuffer_ToContiguous() is moved to memoryview.c. That won't break the ABI eiter. If we want to keep the function in its old place then we can prefix the new functions with _Py and include them in a private header file. That would export new function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15496] harden directory removal for tests on Windows
Jeremy Kloth added the comment: This is a (near) duplicate of issue7443, I think. Partially so it seems. However, my testing with Process Monitor (from sysinterals) shows that most of the access denied errors occur when removing directories. The blind rename-remove dance doesn't work when removing entire directory trees as now the renamed file/directory might be held pending delete when the removing parent directory. For some background for newcomers, see http://support.microsoft.com/kb/159199 For testing, I used regrtest -F -j6 test_import Without patching it would fail consistently (albeit randomly). -- nosy: +jeremy.kloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15495] enable type truncation warnings for gcc builds
Jeremy Kloth added the comment: I'm getting more than thousand warnings: $ CFLAGS=-Wconversion -Wno-sign-conversion ./configure $ LC_ALL=C make -s -j8 21 | tee log $ grep Wconversion log | wc -l 1163 My Win64 buildbot currentlyhas 544 conversion warnings, but it seems something has recently changed with OpenSSL thus causing over 2100 total warnings. -- nosy: +jeremy.kloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15495 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Nick Coghlan added the comment: I was musing about backporting *all* the memoryview fixes, including the buffer lifecycle ones. Antoine and Stefan rightly pointed out that was a bad idea, and not necessary to address this problem. So +1 for backporting just this specific fix, with the necessary infrastructure to make it work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15501] Document exception classes in subprocess module
New submission from Anton Barkovsky: Exception classes from subprocess module are mentioned in the doc but do not have their own entries. I'm attaching patches for 3.3, 3.2 and 2.7 This issue supersedes #14966. -- assignee: docs@python components: Documentation files: subprocess_doc_3.3.patch keywords: patch messages: 166895 nosy: anton.barkovsky, docs@python priority: normal severity: normal status: open title: Document exception classes in subprocess module type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26598/subprocess_doc_3.3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15501 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15501] Document exception classes in subprocess module
Changes by Anton Barkovsky swarmer...@gmail.com: Added file: http://bugs.python.org/file26599/subprocess_doc_3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15501 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15501] Document exception classes in subprocess module
Changes by Anton Barkovsky swarmer...@gmail.com: Added file: http://bugs.python.org/file26600/subprocess_doc_2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15501 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Nick Coghlan added the comment: Ah, the perils of email readers with quote folding and issue trackers without it. The important part of Brett's email is that PEP 420 has started splitting the meta path finder and path entry finder APIs, but importlib still uses a single ABC for both of them. That's probably a mistake, and something we want to address prior to the release of 3.3. I'll create a separate issue for that. I just pushed a docs update to the PEP 420 repo that should address all of my comments. I went ahead with the regular package - initialized package and sys path finder - path entry finder name changes - they just make more sense given the way the components are used. I wanted to avoid regular package as I expect namespace packages to eventually become the norm and initialized packages the more unusual case. sys path finder was simply misleading, as those finders are used for *all* path entries, including those in package __path__ attributes. I haven't reviewed Eric's comments in detail, so I don't know if I also picked up all of those. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
New submission from Nick Coghlan: In the review of #15295, Brett noted that the APIs of meta path finders and path entry finders have now diverged substantially thanks to PEP 420, thus it's rather dubious that they continue to share a single Finder ABC in importlib. -- components: Library (Lib) messages: 166897 nosy: brett.cannon, georg.brandl, ncoghlan priority: release blocker severity: normal stage: needs patch status: open title: Meta path finders and path entry finders are different, but share an ABC type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Nick Coghlan added the comment: #15502 records Brett concern about the merged ABC -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: Attaching patch with test case for long script path. This test failed on my system before the fix and passes after. -- Added file: http://bugs.python.org/file26601/issue-15463-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Changes by Eric V. Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15447] A file is not properly closed by webbrowser._invoke
Anton Barkovsky added the comment: An updated patch with the same issue fixed in Konqueror class. -- Added file: http://bugs.python.org/file26602/fileclose_devnull_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15503] concatenating string in dict unexpected performance
New submission from Petri Heinilä:
In concatenating string in dict somehow radically depends the added string size.
code
import timeit
s1 =
text =
for i in range(1,5):
text += 12345678901234567890
print(str cat 20: {0}s.format(timeit.timeit(s1,number=1)))
s2 =
d = dict()
d[text] =
for i in range(1,5):
d[text] += 12345
print(dict cat 5: {0}s.format(timeit.timeit(s2,number=1)))
s3 =
d = dict()
d[text] =
for i in range(1,5):
d[text] += 1234567890
print(dict cat 10: {0}s.format(timeit.timeit(s3,number=1)))
s4 =
d = dict()
d[text] =
for i in range(1,5):
d[text] += 12345678901234567890
print(dict cat 20: {0}s.format(timeit.timeit(s4,number=1)))
gives:
str cat 20: 0.011670112609863281s
dict cat 5: 2.994051933288574s
dict cat 10: 6.61974310874939s
dict cat 20: 34.230541944503784s
--
assignee: collinwinter
components: Benchmarks
files: string_cat.py
messages: 166901
nosy: collinwinter, hevi
priority: normal
severity: normal
status: open
title: concatenating string in dict unexpected performance
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file26603/string_cat.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15503
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: Is it okay for me to reopen this issue to review the patch to add a test case for file paths longer than 100 characters, or should I create a new issue for that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1610654] cgi.py multipart/form-data
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15503] concatenating string in dict unexpected performance
Alex Gaynor added the comment: Actually, I would argue that it's concatentation of a local variable which has unexpected performance. Logically it should be O(n**2), however due to hacks in CPython it isn't. -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15503] concatenating string in dict unexpected performance
Serhiy Storchaka added the comment:
Yes, the total time of repeated string concatenation is O(N**2). s3 is twice
larger s2, therefore s3 time about twice large s2 time.
In the first case Python use a special optimization which allows O(N) in some
cases. You can deactivate it:
s5 =
text =
for i in range(1,5):
text2 = text
text += 12345678901234567890
print(str cat 20: {0}s.format(timeit.timeit(s5,number=1)))
It's not a bug, it's feature.
--
nosy: +storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15503
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14302] Move python.exe to bin/
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15503] concatenating string in dict unexpected performance
Antoine Pitrou added the comment: It's a FAQ entry: http://docs.python.org/dev/faq/programming.html#what-is-the-most-efficient-way-to-concatenate-many-strings-together -- nosy: +pitrou resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6132] Implement the GIL with critical sections in Windows
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7671] test_popen fails if path contains special char like ;
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4722] _winreg.QueryValue fault while reading mangled registry values
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7686] redundant open modes 'rbb', 'wbb', 'abb' no longer work on Windows
Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7686 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15504] pickle/cPickle saves invalid/incomplete data
New submission from Philipp Lies:
I just stumbled upon a very serious bug in cPickle where cPickle stores the
data passed to it only partially without a warning/error:
#creating a 8GB long random data sting
import os
import cPickle
random_string = os.urandom(int(1.1*2**33))
print len(random_string)
fout = open('test.pickle', 'wb')
cPickle.dump(random_string, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
random_string2 = cPickle.load(fin)
print len(random_string2)
print random_string == random_string2
The loaded string is significantly shorter, meaning that some of the data got
lost while storing the string. This is a serious issue. However, when I use
pickle, writing fails with
error: 'i' format requires -2147483648 = number = 2147483647
so I guess pickle is not able to handle large data, therefore cPickle should
either throw an error as well of pickle/cPickle should be patched to handle
larger data.
Code to reproduce error using numpy (that's how I stumbled upon it):
import numpy as np
import cPickle as pickle
A = np.random.randn(1080,1920,553)
fout = open('test.pickle', 'wb')
pickle.dump(A, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
B = pickle.load(fin)
Here, numpy detects that the amount of data is wrong and throws an error.
However, still serious because saving does not lead to an error so the user
expects that the data are safely stored.
I guess might be related to http://bugs.python.org/issue13555 which is still
open.
Python 2.7.3 on latest Ubuntu with numpy 1.6.2, 64bit architecture, 128GB RAM
--
messages: 166906
nosy: Philipp.Lies
priority: normal
severity: normal
status: open
title: pickle/cPickle saves invalid/incomplete data
type: crash
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15504
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Antoine Pitrou added the comment: For some reasons I was able to reproduce under 64-bit Windows with the 3.3b1 official build, but neither with my own VS9.0-compiled build, nor with the 3.2 official build. To reproduce: class T(tuple): pass ... t = T((1,2)) [] + t (1, 2) [3,] + t # crash I tried to use the debugging symbols but it doesn't help a lot. The primary issue seems to be that the concatenation doesn't raise TypeError, and instead constructs an invalid object which then makes PyObject_Repr() crash. Also, it is not the Python compiler, the same thing happens with constructor calls: list() + T([1,2]) (1, 2) list((3,)) + T([1,2]) # crash And no it doesn't happen with list subclasses: class L(list): pass ... class T(tuple): pass ... L([]) + T([1,2]) Traceback (most recent call last): File stdin, line 1, in module TypeError: can only concatenate list (not T) to list [] + T([1,2]) (1, 2) Also, directly calling the __add__ method doesn't trigger the issue, but operator.add does: l + T([1,2]) (1, 2) operator.add(list(), T([1,2])) (1, 2) list().__add__(T([1,2])) Traceback (most recent call last): File stdin, line 1, in module TypeError: can only concatenate list (not T) to list -- nosy: +brian.curtin, pitrou, tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Antoine Pitrou added the comment: The exact same issue happens when concatenating a list subclass to a tuple: () + L([1,2]) [1, 2] (3,) + L([1,2]) # crash Also, note that in this case a list is returned, not a tuple despite the first operand being a tuple. Conversely: [] + T((1,2)) (1, 2) A tuple is returned, not a list. Which is exactly what happens when calling T.__add__: T.__add__((), T((1,2))) (1, 2) My intuition is that the issue is somewhere in binary_op1() (called by PyNumber_Add) in abstract.c. I can't go much further since my own builds don't exhibit the issue. (in the end, chances are it's a MSVC compiler bug) -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Georg Brandl added the comment: Raising priority. This should be investigated properly before 3.3 final. -- nosy: +georg.brandl priority: high - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set.
New submission from Thomas Wouters: unittest.installHandler incorrectly assumes signal.SIGINT will always be set to a callable object, rather than signal.SIG_DFL or signal.SIG_IGN. This breaks if the test is being executed in an environment that e.g. ignores signal.SIGINT, like a bash script that executes 'make' in a subshell, because an attempt to call the original handler (for whatever reason) causes it to try and call an integer. On top of that, the *tests* for unittest.installHandler in unittest/tests/test_break.py assume not just that signal.SIGINT is set to a callable object, but that they're set to signal.default_int_handler. -- components: Tests messages: 166910 nosy: twouters priority: normal severity: normal status: open title: unittest.installHandler incorrectly assumes SIGINT handler is set. type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15504] pickle/cPickle saves invalid/incomplete data
Martin v. Löwis added the comment: People can probably debate endless about seriousness of an issue. Keep in mind that two factors affect seriousness: what's the impact when it happens (here it is quite bad), and what's the chance that it happens (it's quite low, since it requires you to pickle very long string objects, which only few people ever attempt). So these two cancel them out, in some form. That said, I certainly agree that it needs to be fixed. AFAICT, the issue is that save_string uses int for size and len, when it should use Py_ssize_t. In addition, it shouldn't check for INT_MAX, but 0x7fff, since INT_MAX might be 2**63-1 on systems where int is a 64-bit type - but that should not be a problem on your system. I believe the bug exists in more cases; e.g. saving BINUNICODE. Also, AFAICT, this shouldn't be a problem for 3.x, which already checks for overflow. Then, AFAICT, there is a glitch in the BINUNICODE handling of 3.x, which rejects strings longer than 0x, when the maximum supported length really is 0x7fff. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12288] tkinter SimpleDialog initialvalue
Roundup Robot added the comment: New changeset fd5166fdb978 by Andrew Svetlov in branch '3.2': Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog. http://hg.python.org/cpython/rev/fd5166fdb978 New changeset 2f3ccf4ec193 by Andrew Svetlov in branch 'default': Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog. http://hg.python.org/cpython/rev/2f3ccf4ec193 New changeset f98e2944cb40 by Andrew Svetlov in branch '2.7': Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog. http://hg.python.org/cpython/rev/f98e2944cb40 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15486] Standardised mechanism for stripping importlib frames from tracebacks
Georg Brandl added the comment: Looks good and simplifies things. Green light :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12288] tkinter SimpleDialog initialvalue
Andrew Svetlov added the comment: Fixed. Thank you, Tom. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15506] configure should use PKG_PROG_PKG_CONFIG
New submission from Mike Frysinger: the current configure script open codes the pkg-config look up: AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) rather than using the standard macro from pkg-config's own pkg.m4: PKG_PROG_PKG_CONFIG this causes the build env to not operate exactly like other pkg-config autoconf builds :( simple fix: -AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) +PKG_PROG_PKG_CONFIG -- components: Build messages: 166915 nosy: vapier priority: normal severity: normal status: open title: configure should use PKG_PROG_PKG_CONFIG type: compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set.
Thomas Wouters added the comment: Patch attached. -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file26604/inthandler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Stefan Krah added the comment: Right now major parts of the buffer API are broken for non-trivial buffer definitions. IMHO a backport of the fix doesn't count as a new feature although it needs some new internal functions. This particular bug fix for PyBuffer_ToContiguous() (which would automatically fix memoryview.tobytes() in 2.7 and 3.2) is easy to backport. For non-trivial buffers it's likely though that other problems will show up in versions 2.7 and 3.2. Backporting the *complete* rewrite would be relatively easy, too. But that would change the layout of the MemoryView object etc. Fixing all of #10181 without the drastic changes would be very time consuming (if at all possible). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13555] cPickle MemoryError when loading large file (while pickle works)
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13555 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15504] pickle/cPickle saves invalid/incomplete data
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
Changes by Antoine Pitrou pit...@free.fr: -- versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15506] configure should use PKG_PROG_PKG_CONFIG
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Daniel Holth added the comment: Taking a second look it is pretty good. The only other thing that might be worth mentioning explicitly is that the always present hashes don't actually use OpenSSL. Constructors for hash algorithms that are always present in this module are md5(), sha1(), sha224(), sha256(), sha384(), and sha512(). Additional algorithms may also be available depending upon the OpenSSL library that Python uses on your platform. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set.
Changes by Gregory P. Smith g...@krypto.org: -- assignee: - gregory.p.smith keywords: +needs review nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9803] IDLE closes with save while breakpoint open
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- assignee: - asvetlov nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Gregory P. Smith added the comment: The always present hashes do use openssl if the openssl version hashlib was compiled against supports them. otherwise it falls back to the builtin C implementations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15507] test_subprocess assumes SIGINT is not being ignored.
New submission from Thomas Wouters: test_subprocess's test_send_signal assumes SIGINT is not being ignored, by spawning a new process and expecting it to have the default SIGINT handler . SIGINT can be set to SIG_IGN if the process running the test inherited it from the parent process. -- components: Tests messages: 166921 nosy: twouters priority: normal severity: normal status: open title: test_subprocess assumes SIGINT is not being ignored. versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15507] test_subprocess assumes SIGINT is not being ignored.
Thomas Wouters added the comment: Patch attached to (briefly) set signal.SIGINT to the default in the test. It may make sense to add a feature to subprocess.Popen to ignore/unignore signals (it should only need to support SIG_DFL and SIG_IGN, not other signal handlers, considering there'll be an exec right after.) -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file26605/subprocess.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: Thanks for the review Eric. I'm slogging through these and many other comments, but I now have the docs integrated with trunk, and will probably land them for better or worse in the next day or so. I'll respond just to a few of your comments. Whatever I omit you can consider them fixed! On Jul 28, 2012, at 06:54 AM, Eric Snow wrote: * (glossary.rst) path importer: I like that you pointed out this specific * metapath importer, but aren't path importers something else? [2] Perhaps * the metapath importer doesn't need to be in the glossary. Then again I * like the entry, though I'd change :term:`finder` / :term:`loader` to * metapath importer. Maybe just a different term would work, like sys * path subsystem. Regardless, it is certainly the big dog in the import * machinery and deserves special attention. I certainly struggled with this term. I almost picked PathFinder (or path finder) since that's the name of the actual class used in the implementation, but then I thought this might be too implementation specific. You ask in [2] whether path importer refers specifically to the callables on sys.path_hooks. Can you site a reference for this? I found one reference in PEP 302 to path importer but it's hard to tell exactly what that is referring to. The sys module doesn't use that term. If we agree that path importer is the name of the things on sys.path_hooks, then we need a name for the thing on sys.meta_path that implements the things on sys.path_hook. :) * (glossary.rst) sys path finder: having sys is a nice touch, making it more distinct and more explicit. TBH, I'm not crazy about the term sys path finder either but I couldn't think of anything better. Keep the suggestions coming for both of these terms,. I'll ruminate on it too and leave XXX's in the docs for now. (Maybe as I work through the rest of the comments, something better has already been suggested.) * (importlib.rst) I could have sworn that find_loader() and resolve_name() * were public... There's importlib.find_loader() and importlib.util.resolve_name(), but OTOH, this is not intended to be the importlib library documentation. So I'm happy to leave out such details and add a reference to those docs (done). In a subsequent comment, Nick suggests this whole chapter be called the Import System instead of the Import Machinery, but I've been thinking Import Protocol might be good too. The intent is really to describe the hooks, methods, and attributes used by Python to accomplish import, as well as allow Python code to extend or modify the import machinery. The background at the top of the chapter is really just there to set the stage (and because afaict, nothing like that existed before :). I'm still thinking about this. * (importlib.rst) SourceFileLoader.load_module(): What about when the name * does not match? An ImportError gets raised? Were you suggesting that some additional documentation should be added for this? * (import_machinery.rst) import machinery, end of first paragraph: Note that * importlib.import_module() is the recommended method of calling the import * machinery. I rewrote the introductory paragraphs, and added a mention of import_module(), as well as a section on importlib. Hopefully this will provide enough information for people to figure things out. :) * (import_machinery.rst) how about a section devoted just to the attributes * of modules and packages, perhaps expanding upon or supplanting the related * entries in the data model reference page? I've added an XXX for this. I think the right thing to do is to update the data model chapter, and add a link from here to there. * (import_machinery.rst) Meta path loaders, end of paragraph 2: The finder * could also be a classmethod that returns an instance of the class. I don't understand what you're suggesting here. * (import_machinery.rst) Meta path loaders: If the load fails, the loader * needs to remove any modules... is a pretty exceptional case, since the * modules is not in charge of its parent or children, nor of import * statements executed for it. Is this a new requirement? I don't think so. I lifted it from somewhere (hard to remember exactly where now ;). PEP 302? * (import_machinery.rst) Meta path loaders: too bad there isn't something * like __origin__ for the case where __file__ doesn't make semantic sense, * but you still want to record where the module came from. Yeah. * (import_machinery.rst) I'm surprised __name__ isn't required. Indeed! AFAICT, it was only required by the module object's default repr, but I fixed that when I added module_repr(). :) * (import_machinery.rst) Meta path loaders: what should __package__ be set to * for a top-level module? Great question. I see no official recommendation in anything I've consulted, and I think CPython is all over the map. Some set it to None, some to the empty string. I added a footnote about this, and recommend the empty string,
[issue15295] Import machinery documentation
Éric Araujo added the comment: A small note in passing: “protocol” is used for things like the sequence protocol, the iterator protocol, or closer to home the finder and loader protocols, so it would sound weird or potentially confusing to me. Import system is how I’ve always thought about it (probably took that term from the docs). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15508] __import__.__doc__ has outdated information about level
New submission from Arfrever Frehtes Taifersar Arahesis:
$ python3.2 -c '__import__(os, level=-1)'
$ python3.3 -c '__import__(os, level=-1)'
Traceback (most recent call last):
File string, line 1, in module
ValueError: level must be = 0
$ python3.3 -c 'print(__import__.__doc__)'
__import__(name, globals={}, locals={}, fromlist=[], level=-1) - module
Import a module. Because this function is meant for use by the Python
interpreter and not for general use it is better to use
importlib.import_module() to programmatically import a module.
The globals argument is only used to determine the context;
they are not modified. The locals argument is unused. The fromlist
should be a list of names to emulate ``from name import ...'', or an
empty list to emulate ``import name''.
When importing a module from a package, note that __import__('A.B', ...)
returns package A when fromlist is empty, but its submodule B when
fromlist is not empty. Level is used to determine whether to perform
absolute or relative imports. -1 is the original strategy of attempting
both absolute and relative imports, 0 is absolute, a positive number
is the number of parent directories to search relative to the current module.
$
Also please add a .. versionchanged:: 3.3 note in Doc/library/functions.rst
about no longer allowed negative level.
--
messages: 166925
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: __import__.__doc__ has outdated information about level
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15508
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Brett Cannon added the comment:
To answer a couple of Barry's comments in reply to Eric...
__package__ should be set to the empty string if I'm reading PEP 362 correctly
(and importlib isn't broken): When the import system encounters an explicit
relative import in a module without __package__ set (or with it set to None),
it will calculate and store the correct value (__name__.rpartition('.')[0] for
normal modules and __name__ for package initialisation modules. If someone
sets __package__ to None, then importlib fills it in as necessary.
As for the diagram(s), I have attached the overall PDF that I still have from
my original Omnifgraffle file (which I don't have a license to anymore) that I
built my PyCon 2008 presentation with. It's probably outdated at this point. I
will have to redo them for my PyCon Argentina/Brasil (maybe US?) import talks
anyway.
--
Added file: http://bugs.python.org/file26606/__import__.pdf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15295
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15508] __import__.__doc__ has outdated information about level
Changes by Brett Cannon br...@python.org: -- assignee: - brett.cannon resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15508] __import__.__doc__ has outdated information about level
Roundup Robot added the comment: New changeset 2a4ca86cc2b7 by Brett Cannon in branch 'default': Issue #15508: Fix the docstring for __import__ to not mention negative http://hg.python.org/cpython/rev/2a4ca86cc2b7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15508] __import__.__doc__ has outdated information about level
Arfrever Frehtes Taifersar Arahesis added the comment: What about the suggested change in Doc/library/functions.rst? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Stefan Krah added the comment:
I can reproduce this exclusively with the pgupdate build:
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=win32
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=win32
PCbuild\Win32-pgo\python.exe
Python 3.3.0b1 (default, Jul 30 2012, 23:45:42) [MSC v.1600 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
from collections import namedtuple
foo = namedtuple('foo', '')
[1] + foo()
Interpreter exits silently here. So it could be either an optimizer
bug or it's a Python bug exposed by the optimizer making draconian
assumptions at the highest level (c.f. clang exposing overflows).
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8847
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
