[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Sven Marnach added the comment: The current behaviour of islice() seems inconsistent with the rest of Python. All other functions taking start, stop and step arguments like slice(), range() and itertools.count() do accept integer-like objects. The code given as "roughly equivalent" in the documentation of islice() accepts integer-like objects, and so does regular list slicing. In fact, the __index__() method was introduced in PEP 357 specifically for slicing. In Python 2, islice() supported it as well. I think the expectation that islice() in Python 3 also supports it is entirely reasonable, and I can't see any strong arguments for breaking that assumption. -- nosy: +smarnach ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Sven Marnach s...@marnach.net added the comment: The semantics of associated application change considerably from operating system to operating system. As an example, ``os.startfile(a.py)`` will usually run `a.py` in the Python interpreter, while ``xdg-open a.py`` it will usually open the source code in an editor on Linux. This might reduce the overall usefulness of the proposed ``shutil.launch()`` function. -- nosy: +smarnach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't
New submission from Sven Marnach s...@marnach.net: As has been pointed out before on python-dev [1], the mandatory version of '__future__.absolute_import' does not match reality. In Python 2.7, absolute imports are not the default. [1]: http://article.gmane.org/gmane.comp.python.devel/125446 The attached patch should fix the documentation and Lib/__future__.py. I set the mandatory version to (3, 0, 0, alpha, 0), in accordance with other features that became mandatory in Py3k, though there never was a 3.0a0 release. I double-checked that absolute imports already were the default in 3.0a1. The patch should probably be applied to all branches. -- assignee: docs@python components: Documentation, Library (Lib) files: absolute_import.patch keywords: patch messages: 157474 nosy: docs@python, smarnach priority: normal severity: normal status: open title: __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25118/absolute_import.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14456] Relation between threads and signals unclear
Sven Marnach s...@marnach.net added the comment: Thanks, Antoine! It's perfectly clear now, and the newly introduces headlines are a definite improvement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14456 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14456] Relation between threads and signals unclear
New submission from Sven Marnach s...@marnach.net: The documentation of the 'signal' module states on the one hand [T]he main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). On the other hand, it provides the function 'pthread_kill()': Send the signal signum to the thread thread_id, another thread in the same process as the caller. The signal is asynchronously directed to thread. These two passages are in contradiction to each other. The documentation also states that only the main thread can set signal handlers -- if this is true, it is utterly unclear how sending signals to other threads is useful. Probably the documentation wasn't fully updated when the above function was introduced. -- assignee: docs@python components: Documentation messages: 157156 nosy: docs@python, smarnach priority: normal severity: normal status: open title: Relation between threads and signals unclear versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14456 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose pthread_sigmask(), pthread_kill(), sigpending() and sigwait() in the signal module
Sven Marnach s...@marnach.net added the comment: The documentation has been left in a confusing state by this patch -- at least confusing to me. I've created issue14456 with further details. -- nosy: +smarnach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14456] Relation between threads and signals unclear
Sven Marnach s...@marnach.net added the comment: For reference: the functions 'pthread_kill()' etc. were intrduced in issue8407. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14456 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14165] The new shlex.quote() function should be marked New in version 3.3
New submission from Sven Marnach s...@marnach.net: The function shlex.quotes() [1] does not yet exist in Python 3.2 [2], so it should be marked New in version 3.3. in the docs. I double-checked that it really does not yet exist in 3.2 and is not only missing from the 3.2 documentation. [1]: http://docs.python.org/dev/library/shlex.html#shlex.quote [2]: http://docs.python.org/py3k/library/shlex.html -- assignee: docs@python components: Documentation messages: 154693 nosy: docs@python, smarnach priority: normal severity: normal status: open title: The new shlex.quote() function should be marked New in version 3.3 versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13585] Add contextlib.CleanupManager
Sven Marnach s...@marnach.net added the comment: I think that the fact that Nick got the code to close multiple files wrong underlines that it is difficult to get right currently. Nick's code try: files = [open(fname) for fname in names] # ... finally: for f in files: f.close() only closes the files if all of them were opened successfully. Moreover, `file.close()` can fail for various reasons, which would result in all remaining files being left open. When we fix both problems, the code becomes try: files = [] for fname in names: files.append(open(fname)) # ... finally: for f in files: try: f.close() except IOError: pass I think everyone will agree that the version using 'CleanupManager' is nicer. To be fair, we should note that the need to open many files simultaneously is not very common -- usually, we can make to with opening the files one by one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13585 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13585] Add contextlib.CleanupManager
Sven Marnach s...@marnach.net added the comment: There is actually a second thread on python-ideas on a very similar topic, see http://mail.python.org/pipermail/python-ideas/2011-December/013021.html The two main advantages of the proposed CleanupManager over try/finally blocks are 1. You can add a clean-up function conditionally. In a try/finally block, you would need a flag, which would scatter the single idea more across the code. Example: with CleanupManager() als mngr: if f is None: f = open(some_file) mngr.register(f.close) # do something with f (possibly many lines of code) seems much clearer to me than f_needs_closing = False if f is None: f = open(some_file) f_needs_closing = True try: # do something with f (possibly many lines of code) finally: if f_needs_closing: f.close() The first version is also much more in the spirit of context managers. You state at the beginning we open the file, and guarantee that it will be closed, and we know right from the start that we don't have to bother with it again. 2. CleanupManager could replace several nested try/finally blocks, which again might lead to more readable code. On the other hand, people who never saw ContextManager before will have to look it up, which will impair readability for those people. Adding this as a cookbook recipe first seems like a good idea. -- nosy: +smarnach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13585 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13332] execfile fixer produces code that does not close the file
New submission from Sven Marnach s...@marnach.net: The execfile fixer of the 2to3 script replaces the 2.x code execfile(a.py) by exec(compile(open(a.py).read(), a.py, 'exec')) The new code does not explicitly close the file. This is not usually a problem in CPython, but 1. the code will throw a RessourceWarnings if enabled and 2. other Python implementation don't close the file immediately. (I think the 2to3 script should be as implementation-independent as possible.) The obvious fix would be to use a with-statement: with open(a.py) as new_name: exec(compile(new_name.read(), a.py, 'exec')) If this is to be changed, I'd be happy to prepare a patch. -- components: 2to3 (2.x to 3.x conversion tool) messages: 146918 nosy: smarnach priority: normal severity: normal status: open title: execfile fixer produces code that does not close the file type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13332 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13332] execfile fixer produces code that does not close the file
Sven Marnach s...@marnach.net added the comment: @Petri: Yes, that's what the BaseFix.new_name() method is for. @Antoine: I thought about this, though I don't think it is very common to call execfile() as part of an expression. The whole statement containing the function call would need to be wrapped. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13332 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13332] execfile fixer produces code that does not close the file
Sven Marnach s...@marnach.net added the comment: Getting the general case right seems a bit too difficult. Examples like [execfile(n) for n in names if condition(n)] execfile(execfile(n1) or n2) try: 1 / 0 except execfile(n) or ZeroDivisionError: pass would require rather complex transformations to get exactly matching behaviour, and obviously we don't want to explode the fixer code to support such nonsense. I think it is enough to cover the case of an execfile() call that forms a statement of its own. Browsing through the first ten pages of a Google code search for execfile didn't reveal any other uses, except for a few that aren't covered by the current version of the fixer either. [1] I'd suggest to simply throw a could not convert warning for any other uses of execfile(). Opinions? [1]: http://www.google.com/codesearch#yqvQ9RM69FY/mercurial/lsprof.pyq=execfilesq=l=111ct=rccd=49 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13332 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Sven Marnach s...@marnach.net added the comment: Thanks for the updates, Mark. I was just about to look into this again. The changes are fine with me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Sven Marnach s...@marnach.net added the comment: Victor Stinner wrote: If would be nice to have a PyLong_CompareLong() function. In most cases, global variables Py_Zero and Py_One would be enough to simplify this kind of code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Sven Marnach s...@marnach.net added the comment: Mark, thanks again for your comments. (I never looked at the Python source code before, so tey are highly appreciated.) I uploaded a new version of the patch hopefully. -- Added file: http://bugs.python.org/file23441/range-compare-v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13199] slice_richcompare() might leak an object in rare cases
New submission from Sven Marnach s...@marnach.net: If exactly one of the two tuple allocations in [1] fails, the tuple that is successfully allocated won't be freed. (This probably never happened. Are you interested in this kind of bug report anyway?) [1]: http://hg.python.org/cpython/file/f6b3ad301851/Objects/sliceobject.c#l349 -- components: Interpreter Core messages: 145689 nosy: smarnach priority: normal severity: normal status: open title: slice_richcompare() might leak an object in rare cases ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13200] Add start, stop and step attributes to range objects
New submission from Sven Marnach s...@marnach.net: As discussed on python-ideas [1], range objects should expose their start, stop and step values as read-only data attributes. I've attached a patch to this end. I'll open a separate issue for range comparison. [1]: http://mail.python.org/pipermail/python-ideas/2011-October/012356.html -- components: Interpreter Core files: range-members messages: 145701 nosy: smarnach priority: normal severity: normal status: open title: Add start, stop and step attributes to range objects type: feature request Added file: http://bugs.python.org/file23425/range-members ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
New submission from Sven Marnach s...@marnach.net: It seems some sort of consensus on how to compare range objects has emerged from the python-ideas discussion on comparison of range objects [1]. The attached patch defines '==' and '!=' for range object equality based on the sequence of values they represent. The other comparison operators are left NotImplemented. [1]: http://mail.python.org/pipermail/python-ideas/2011-October/012376.html -- files: range-compare messages: 145705 nosy: smarnach priority: normal severity: normal status: open title: Implement comparison operators for range objects Added file: http://bugs.python.org/file23426/range-compare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13200] Add start, stop and step attributes to range objects
Sven Marnach s...@marnach.net added the comment: Thanks, Éric. Added new version of the patch. (Could I also edit the old one?) -- Added file: http://bugs.python.org/file23427/range-members.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Sven Marnach s...@marnach.net added the comment: Mark, thanks for your comments. Here's a new version of the patch, I answer on Rietveld. -- Added file: http://bugs.python.org/file23429/range-compare-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13145] Documentation of PyNumber_ToBase() wrong
New submission from Sven Marnach s...@marnach.net: The documentation of PyNumber_ToBase() [1] states When base is not 2, 8, 10, or 16, the format is 'x#num' where x is the base. In reality, the function does not accept any bases different from 2, 8, 10, or 16, as can be seen in the source code of _PyLong_Form() [2], which is called from PyNumber_ToBase() to do the actual conversion. The patch fixes the documentation. [1]: http://docs.python.org/c-api/number.html#PyNumber_ToBase [2]: http://hg.python.org/cpython/file/f924e0f62bcb/Objects/longobject.c#l1663 -- assignee: docs@python components: Documentation files: pynumber-tobase-doc.patch keywords: patch messages: 145297 nosy: docs@python, smarnach priority: normal severity: normal status: open title: Documentation of PyNumber_ToBase() wrong Added file: http://bugs.python.org/file23367/pynumber-tobase-doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13145 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2
New submission from Sven Marnach s...@marnach.net: The sidebar on http://docs.python.org/release/3.1.3/ names 3.2 as the development version of Python, while the link points to 3.3. The sidebar on http://docs.python.org/py3k/ links to 3.1 as the stable version -- obviously a relict from the time when 3.2 was in development. (This could be fixed in Doc/tools/sphinxext/indexsidebar.html of the respective branches.) -- assignee: docs@python components: Documentation messages: 145084 nosy: docs@python, smarnach priority: normal severity: normal status: open title: Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2 versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Sven Marnach s...@marnach.net added the comment: The behaviour discussed in this thread does not seem to be reflected in Python's documentation. The documentation of __eq__() [1] doesn't mention that objects should compare equal to themselves. [1]: http://docs.python.org/dev/reference/datamodel.html#object.__eq__ There are several places in the documentation that are wrong for NaNs; just one example is the documentation of sequence types [2], which states: This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length. [2]: http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range It's probably not worthwhile to fix all the places in the documentation that implicitly assume that objects compare equal to themselves, but it probably is a good idea to mention that __eq__() implementations should fulfil this assumption to avoid strange behaviour when used in combination with standard containers. Any thoughts? -- nosy: +smarnach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
