[issue18885] handle EINTR in the stdlib
STINNER Victor added the comment: With PEP 475 now implemented (see Issue 23648), perhaps this could be closed? Or is there something else to be done? Yes, this issue was fully fixed by the implementation of the PEP 475 in Python 3.5. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24390] Python 3.4.3 64 bits is not high dpi aware
Amaury Forgeot d'Arc added the comment: The Python program itself has no UI and cannot be marked as DPI aware. Instead, applications should call the win32 function SetProcessDPIAwareness: https://msdn.microsoft.com/en-us/library/windows/desktop/dn302122 -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Antoine Pitrou added the comment: It's not a problem, since str *is* unicode in Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24390] Python 3.4.3 64 bits is not high dpi aware
Ivan Bykov added the comment: Python 3.5.0b2 (v3.5.0b2:7a088af5615b, May 31 2015, 06:22:19) [MSC v.1900 64 bit (AMD64)] on win32 Type copyright, credits or license() for more information. import ctypes ctypes.windll.user32.GetSystemMetrics(1) 1067 #must be 1600 #Python 3.5 also affected -- versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Serhiy Storchaka added the comment: Such libraries already have a problem. Both str and unicode pickled in Python 2 are unpickled as str in Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24390] Python 3.4.3 64 bits is not high dpi aware
Ivan Bykov added the comment: SetProcessDpiAwareness not available for Windows 7. For Windows 7 available SetProcessDPIAware, but: Note SetProcessDPIAware is subject to a possible *race* *condition* if a DLL caches dpi settings during initialization. For this reason, it is recommended that dpi-aware be set through the application (.exe) *manifest* rather than by calling SetProcessDPIAware. https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543%28v=vs.85%29.aspx -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser
Serhiy Storchaka added the comment: Started topic on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/153655 . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Serhiy Storchaka added the comment: Alexandre, Antoine, what are your thoughts? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Serhiy Storchaka added the comment: Does such API even exist? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Antoine Pitrou added the comment: I wouldn't be very surprised if third-party libraries enforce such typing, yes. If your library has a clear text/bytes separation, it makes sense to enforce it at the API level, to avoid mistakes by users. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full()
Andrew Svetlov added the comment: Raymond, is there known custom third-party queue class derived from queue.Queue? I believe all those are in stdlib only. Also locking guarantee is promised by comment in source code only, documentation says nothing about it. I believe proposed change will not make any harm, but ok with closing as wontfix if you fill it's dangerous. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Increase pickle compatibility
Antoine Pitrou added the comment: Won't that fail if a Python 2 API accepts only unicode strings? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full()
Serhiy Storchaka added the comment: Yes, there are. https://code.openhub.net/search?s=%22def%20_qsize%22%20%22import%20Queue%22pp=0ff=1mp=1ml=1me=1md=1filterChecked=true -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError
Raymond Hettinger added the comment: One other thought: Returning NotImplemented may be an easy change but it isn't clear that it would provide a sensible capability for mapping views. The non-iterable *other* argument would need to have a __ror__() method than could do something useful with a KeysView or ItemsView argument. That seems like an improbable use case (which is why I presume this has never come up before). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24413 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9427] logging.error('...', exc_info=True) should display upper frames, too
Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9427 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Antoine Pitrou added the comment: He accepted it already: A small last-minute optimization is not a release-blocker. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23891] Tutorial doesn't mention either pip or virtualenv
Roundup Robot added the comment: New changeset bb51d486a899 by Tal Einat in branch '3.4': #23891: correctly refer to PyPI as Python Package Index https://hg.python.org/cpython/rev/bb51d486a899 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23891 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full()
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22983] Cookie parsing should be more permissive
Changes by Tim Pierce twpie...@gmail.com: -- nosy: +Tim Pierce ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23891] Tutorial doesn't mention either pip or virtualenv
Skip Montanaro added the comment: Small nit... The venv.patch file refers to Python Packaging Index. It's the Python Package Index. -- nosy: +skip.montanaro Added file: http://bugs.python.org/file39663/ppi.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23891 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24228] Interpreter triggers segmentation fault at the starting
doz added the comment: The problem is only present with gcc optimization -Os . Not present with -O0 ,O1, O2, O3. Do you have an idea of the gcc pass responsible to that ? (I have also a similar problem with openssl) regards -- resolution: - third party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24417] Type-specific documentation for __format__ methods
Changes by Eric V. Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Serhiy Storchaka added the comment: Larry, do you accept the patch for 3.5? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag stage: - needs patch type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] slice.literal notation
Tal Einat added the comment: (This should probably be discussed on the Python Ideas mailing list...) I definitely like the idea of being able to construct slices etc. using [] syntax. I think this should be considered even if it is decided not to change the repr() of slices. An important note here is that this is about more than slices: $ python3 Python 3.4.2 (default, Feb 23 2015, 21:16:28) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type help, copyright, credits or license for more information. class A: ... def __getitem__(self, *args): ... print(repr(args)) ... a = A() a[0] (0,) a[0:1] (slice(0, 1, None),) a[0:1, ..., 1:2] ((slice(0, 1, None), Ellipsis, slice(1, 2, None)),) a[0:1, 2] ((slice(0, 1, None), 2),) Indeed, Joe's suggested slice.literal supports all of this, but we can't just modify slice to handle all of these cases. What I'm missing is a way to use such an object to actually index/slice something. The only way I can currently think of is using a.__getitem__(), but that's quite ugly IMO. -- nosy: +taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Stefan Behnel added the comment: See issue 24400 regarding a split of yield-based generators and async-def coroutines at a type level. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Changes by Yury Selivanov yseliva...@gmail.com: -- hgrepos: +312 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24351] string.Template documentation incorrectly references identifiers
Changes by Barry A. Warsaw ba...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: Cleaned up the patch a little bit. -- Added file: http://bugs.python.org/file39665/corotype.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
New submission from Antoine Pitrou: This is what happens when building Python with conda-build (which implies doing make install with a custom prefix): [...] if test xupgrade != xno ; then \ case upgrade in \ upgrade) ensurepip=--upgrade ;; \ install|*) ensurepip= ;; \ esac; \ LD_LIBRARY_PATH=/home/antoine/miniconda3/conda-bld/work/cpython-default ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Ignoring indexes: https://pypi.python.org/simple/ Requirement already up-to-date: setuptools in /home/antoine/.local/lib/python3.5/site-packages Requirement already up-to-date: pip in /home/antoine/.local/lib/python3.5/site-packages [...] Note that conda-build *does* set PYTHONNOUSERSITE to make builds as isolated as possible, but the Python Makefile deliberately ignores it using python -E! -- components: Build messages: 245078 nosy: dstufft, ncoghlan, pitrou priority: normal severity: normal status: open title: make install will not install pip if already present in user site-packages type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24351] string.Template documentation incorrectly references identifiers
Roundup Robot added the comment: New changeset 20bf84cd38bc by Barry Warsaw in branch '3.4': - Issue #24351: Clarify what is meant by identifier in the context of https://hg.python.org/cpython/rev/20bf84cd38bc New changeset 0fa48f581fe3 by Barry Warsaw in branch '3.5': - Issue #24351: Clarify what is meant by identifier in the context of https://hg.python.org/cpython/rev/0fa48f581fe3 New changeset 1cdedc9a9e9f by Barry Warsaw in branch 'default': - Issue #24351: Clarify what is meant by identifier in the context of https://hg.python.org/cpython/rev/1cdedc9a9e9f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: One more patch fixing minor bug in types.coroutine + a unittest for that. The patch should be ready for reviews. -- Added file: http://bugs.python.org/file39666/corotype.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
Donald Stufft added the comment: We should probably pass ``-s`` to the ensurepip call. Adding 2.7 here as well because I think this will probably affect more than just the Makefile, probably the Windows installers and OSX installers too. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
Antoine Pitrou added the comment: Do we need to add Steve and Ned for the installers? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Stefan Behnel added the comment: I added some review comments. The main thing is that the coroutine type should be awaitable. For reference, here's my current implementation for Cython. It's a bit more involved as it needs to support Python 2.6+. I may also add some special casing for CPython's own coroutine type when compiling in Py3.5 if this change makes it in. https://github.com/cython/cython/blob/bb0dec2fab91cbde443e6756c3dc29ee009caba7/Cython/Utility/Coroutine.c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Tal Einat added the comment: First, if pickle a namedtuple, it can't be unpickled in previous versions. True, but I don't think Python goes as far as to promise that objects pickled in one version can be unpickled in previous versions. Second, namedtuple is slower and larger than tuple, so it shouldn't be used in memory or performance critical code. True, but I doubt that such tuples are often used extensively in performance-critical areas of code. Also, code which does care about this could immediately convert these namedtuples into plain tuples, which would be backwards compatible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Carl Kleffner added the comment: The most robust way to support a specific mingw-w64 distribution is to copy a python import library generated by this specific toolchain and the provided import library for the corresponding msvcrXX.dll runtime into the libs folder. This has to be performed by the user with the help of gendef and dlltool. Another atempt is to install and use a specific mingw-toolchain that copies these files into the libs folder during install. Such a toolchain will be provided in the near future as 'mingwpy' toolchain for python2.7-3.4. -- nosy: +carlkl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] slice.literal notation
Tal Einat added the comment: (see https://mail.python.org/mailman/listinfo/python-ideas) But for x = [1,2,3,4], how will x[y] work for all of the following values of y? y = slice.literal[0] y = slice.literal[1:2] y = slice.literal[0:1, ..., 3] NumPy's s_ magic object is a factory, returning objects of different types depending on the given input. If you want an actual slice.literal class, then you'll have to supply a way to convert it into an object usable for indexing/slicing, e.g.: y = slice.literal[0:1] [1,2,3,4][y.as_indexer] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Tal Einat added the comment: Is there any way that this could break existing code? -- nosy: +taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Serhiy Storchaka added the comment: No, it is not fully backwards-compatible. First, if pickle a namedtuple, it can't be unpickled in previous versions. Second, namedtuple is slower and larger than tuple, so it shouldn't be used in memory or performance critical code. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Baptiste Mispelon added the comment: I didn't know about issues with pickling. As for the performance issue, is date.isocalendar() really performance critical? I found a precedent for replacing a tuple by a namedtuple: https://hg.python.org/cpython/rev/ef72142eb8a2 I'm trying my hand at writing a patch (I'm a new contributor) but it seems the code is implemented twice: both in Lib/ (python) and in Modules/ (C). I'm having a hard time figuring out how to conjure up a namedutple from the C code. Any hepl is appreciated. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Serhiy Storchaka added the comment: The patch is not so harmless. First, my change in BZ2File is not correct, because reading every line should be guarded with a lock (BZ2File is threading-safe). Second, for now all three compressing files are not only iterables, but iterators. iter(f) returns f, and changing this can have non-obvious effects. I think the patch is too complex for 3.5, we should have more time to analyze all consequences. -- stage: commit review - patch review versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Baptiste Mispelon added the comment: As far as I know, using a namedtuple in place of a tuple is fully backwards-compatible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Tal Einat added the comment: You can take a look at lru_cache_cache_info in Modules/_functoolsmodule.c for an example of namedtuple instantiation in C code. But that code gets the namedtuple class as a parameter. This is not my area of expertise, but you could try using PyObject_CallFunction to call the Python collections.namedtuple function, keep the result as a module attribute, and then call that whenever you want to create an instance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Baptiste Mispelon added the comment: Here's a second attempt at a patch which seems to work. I don't know C at all but I used _decimal.c to try and figure out how to use namedtuple in C. The code compiles and the datetime test suite runs. I've added a test for the new feature and a note in Misc/NEWS as well as a versionadded note in the relevant documentation. Let me know if I've missed anything. -- keywords: +patch Added file: http://bugs.python.org/file39667/issue24416_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
Changes by Ned Deily n...@acm.org: -- nosy: +ned.deily stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: A quick scan of which files have been modified suggests the new opcode still needs docs (although I think the PEP 492 docs in general are still pending, in which case, this could just be rolled into that) I'll review the full patch later today (too big to review on my phone) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24419] In argparse action append_const doesn't work for positional arguments
New submission from py.user:
Action append_const works for options:
import argparse
parser = argparse.ArgumentParser()
_ = parser.add_argument('--foo', dest='x', action='append_const', const=42)
_ = parser.add_argument('--bar', dest='x', action='append_const', const=43)
parser.parse_args('--foo --bar'.split())
Namespace(x=[42, 43])
Action append_const works for single positionals:
import argparse
parser = argparse.ArgumentParser()
_ = parser.add_argument('foo', action='append_const', const=42)
_ = parser.add_argument('bar', action='append_const', const=43)
parser.parse_args([])
Namespace(bar=[43], foo=[42])
Action append_const doesn't work for positionals in one list:
import argparse
parser = argparse.ArgumentParser()
_ = parser.add_argument('foo', dest='x', action='append_const', const=42)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py,
line 1282, in add_argument
ValueError: dest supplied twice for positional argument
_ = parser.add_argument('bar', dest='x', action='append_const', const=43)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py,
line 1282, in add_argument
ValueError: dest supplied twice for positional argument
parser.parse_args([])
Namespace()
The reason is that a positional argument can't accept dest:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', dest='x')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py,
line 1282, in add_argument
ValueError: dest supplied twice for positional argument
--
components: Library (Lib)
messages: 245099
nosy: py.user
priority: normal
severity: normal
status: open
title: In argparse action append_const doesn't work for positional arguments
type: behavior
versions: Python 3.3, Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24419
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: Nick Coghlan added the comment: A quick scan of which files have been modified suggests the new opcode still needs docs (although I think the PEP 492 docs in general are still pending, in which case, this could just be rolled into that) Sure. If the patch looks good I'll update it with the docs! -- nosy: +Yury.Selivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: (although I think the PEP 492 docs in general are still pending, in which case, this could just be rolled into that) Actually most of pep 492 docs are merged already (including new opcodes) via issue24180. They can be definitely improved though (I'll try to reserve some time just for that closer to the rc) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Baptiste Mispelon added the comment: For the name, I took (un)inspiration from ParseResult: https://docs.python.org/3/library/urllib.parse.html?highlight=urlparse#urllib.parse.ParseResult Any better suggestion is welcome of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Baptiste Mispelon added the comment: Some C code cleanups suggested by haypo. -- Added file: http://bugs.python.org/file39668/issue24416_3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Larry Hastings added the comment: Sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: Please find attached a new patch. Stefan, while working on the patch, I (re-)discovered that __await__ for coroutines should return an iterator that also implements '.send', '.throw', and '.close', to comply with PEP 380 yield from implementation: https://www.python.org/dev/peps/pep-0380/#proposal Please try to compile this python file: https://gist.github.com/1st1/4ee1d072309068dd2798 -- Added file: http://bugs.python.org/file39669/corotype.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: Nick, Guido, I think we should commit this. While working on this I'm getting more and more confident that it's the right thing to do. I like that coroutines implement __await__ in the latest patch -- PEP 492 just now clicks with PEP 380. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Tal Einat added the comment: Now for the color of the bike-shed: What should the namedtuple returned by date.isocalendar() be named? Perhaps CalendarDate or DateTuple? Baptiste's patches use ISOCalendarResult. In my opinion that is a poor name since it does not tell you anything about what it represents (you have to know or look up what isocalendar() returns). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24415] SIGINT always reset to SIG_DFL by Py_Finalize()
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
New submission from Baptiste Mispelon: Currently, `date.isocalendar()` returns a plain tuple of (year, week, weekday). It would be a bit more useful if this tuple could be made into a namedtuple (with fields year, week and weekday). -- components: Library (Lib) messages: 245061 nosy: bmispelon priority: normal severity: normal status: open title: Return a namedtuple from date.isocalendar() versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24415] SIGINT always reset to SIG_DFL by Py_Finalize()
New submission from ABalmosan:
We use the Python lib as part of a larger process. This process sets its own
signal handlers to achieve the expected behavior of the process.
We use Py_InitializeEx(0) to prevent Python to install its own signal handlers.
On process reconfigure we shutdown Python with Py_Finalize() to call
Py_InitializeEx(0) anew.
Even so Py_InitializeEx(0) did not touch any signal and especially not SIGINT,
Py_Finalize() resets unconditionally SIGINT to SIG_DFL.
The result is that our process terminates immediately on SIGINT instead of
execution its shutdown procedure which was handled by the orginal installed
SIGINT handler.
The problem is visible in the python code in
Modules/signalmodule.c:
static void
finisignal(void)
{
int i;
PyObject *func;
PyOS_setsig(SIGINT, old_siginthandler);
old_siginthandler = SIG_DFL;
In Python/pythonrun.c Py_InitializeEx()I find:
if (install_sigs)
initsigs(); /* Signal handling stuff, including initintr() */
Also I wonder by whom PyOS_InitInterrupts() is called. It would unconditionally
install the Python signal handler even if Py_InitializeEx(0) was once executed.
--
components: Interpreter Core
messages: 245060
nosy: ABalmosan
priority: normal
severity: normal
status: open
title: SIGINT always reset to SIG_DFL by Py_Finalize()
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24415
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Ben Darnell added the comment: 4. While this patch addresses initial request from Ben only partially (generator-based coroutines still require __instancecheck__), A partial solution doesn't mean much to me: as long as the __instancecheck__ is sometimes necessary, I'll have to use inspect.iscoroutine all the time instead of using singledispatch with Awaitable. If anything, this just magnifies the risk of mysterious failures as things will work with async def but not yield from. I think I'd rather not have the ABC than have one with this kind of quirk. All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: all generators have all the methods necessary to satisfy the coroutine interface, but you can't use them as coroutines without some magical indication that that's what you meant. Prior to 3.5, a coroutine was just a callable returning a generator. Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type, which causes problems when the underlying generator function is wrapped in complex ways (https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/testing.py#L476). Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real. Was there a problem in practice with Python 3.4's asyncio in which people used yield from in a coroutine with generators that were intended to be iterators instead? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22836] Broken Exception ignored in: message on exceptions in __repr__
Martin Panter added the comment: Updated the patch to address an oversight in the new test cases. I think Issue 6294 is probably the same underlying issue. The patch there could be used as the basis for a Python 2 patch. My patches here are for Python 3, and I suspect the code is significantly different in each version, because the error messages are different. Comparison (for bikeshedding etc) with the message produced by the “traceback” module when str() fails: try: ... raise BrokenStrException(message) ... except BrokenStrException: ... print_exc() ... raise ... Traceback (most recent call last): File stdin, line 2, in module BrokenStrException: unprintable BrokenStrException object Traceback (most recent call last): File stdin, line 2, in module __main__.BrokenStrException: str() failed -- stage: - patch review versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39670/unraisable-continue.v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22836 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: [..] Why is it anti-duck-typing? Awaitable is an object that implements __await__. With this patch coroutines are a separate type with __await__ (although, ceval doesn't use it to make things faster). In asyncio we check for coroutine-ness only to raise errors if someone passes a wrong object, or to make @asyncio.coroutine work (which will go away eventually). Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type [..] Not sure what you mean here. It doesn't matter what callable is. It only matters if it returns a native coroutine, a generator-based coroutine, or an object with __await__. Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real. Well, 'await' expression is a new operator, and it makes total sense to limit its usage only to awaitables. Awaiting on a generator that yields a fibonacci sequence just doesn't make any sense, and *is* error prone. I think it would be a major mistake to allow this just to make things a little bit more convenient during the transition period. This particular patch does not divide generators in awaitables and non-awaitables, it introduces a new type for 'async def' coroutines. All confusion with old generator-based coroutines and @coroutine decorator is here only because we try to be backwards compatible; the compatibility layer can be removed in 3.7 or 3.8. Was there a problem in practice with Python 3.4's asyncio in which people used yield from in a coroutine with generators that were intended to be iterators instead? Yes, a lot of people were confused where they have coroutines and where they have generators, and this was even mentioned in the Rationale section of the PEP. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24356] venv documentation incorrect / misleading
Tal Einat added the comment: See also the recent addition of a section on venv to the Tutorial section of the docs (Doc/tutorial/venv.rst, issue23891). The wording there and in the module docs should at least be consistent with each other. -- nosy: +taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24356 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24417] Type-specific documentation for __format__ methods
New submission from Skip Montanaro: I am only now just prying my fingers off printf-style string formatting. The new syntax always seemed Perl-like to me, so I ignored it. Finally, yesterday, I got some cheat sheet pointers from comp.lang.python and dove in. I hit a minor roadblock when I couldn't find any type-specific documentation for the various __format__ methods. In the documentation on the format() builtin (https://docs.python.org/3.5/library/functions.html#format) I read, The interpretation of format_spec will depend on the type of the value argument... which led me to believe I would find something about (for example) float.__format__ in the section on floats (https://docs.python.org/3.5/library/stdtypes.html#typesnumeric). I realize now that the documentation for many formats is in the string documentation (https://docs.python.org/3.5/library/string.html#formatspec), but I think it would still be useful to have at least stubs in the documentation for the __format__ method of the various builtin types, even if all those stubs to is refer the reader to the string documentation. I started to work on a patch, but I quickly got myself confused about where to describe sometype.__format__. Perhaps it's time that stdtypes.rst is broken into multiple files, with the structure of the documentation for the various builtin types made more uniform. For instance, int and float have sections describing methods, while list, tuple, set, and dict don't. -- assignee: docs@python components: Documentation messages: 245063 nosy: docs@python, skip.montanaro priority: normal severity: normal status: open title: Type-specific documentation for __format__ methods ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Martin Panter added the comment: This patch adds an entry to the What’s New for 3.5 (though maybe it will have to be 3.6), and adds three tests to check that next() raises ValueError when the files have been closed. -- Added file: http://bugs.python.org/file39662/decomp-optim.v4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Benjamin Gilbert added the comment: Is there any reason an import library generated by a particular MinGW version shouldn't be usable by any other MinGW version? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: On June 9, 2015 at 11:11:11 PM, Ben Darnell (rep...@bugs.python.org) wrote: [..] The type of the callable matters for the types.coroutine decorator. In order to get a coroutine object instead of a generator object, I must apply types.coroutine to the actual underlying generator, and not any wrapper. I get it now, thanks for explaining. FWIW, I’ve recently updated types.coroutine: https://github.com/python/cpython/blob/eae2bd7c0718b8e4333bd16134e37810e32c050c/Lib/types.py#L164 Instead of unwrapping the callable, it wraps its result with a special object with __await__. For instance, this enables regular functions (not generator functions) that are decorated with @types.coruoutine and return a generator, or a generator-like object compiled with Cython to work with ‘await’. Maybe this is something you can use in Tornado? There is also issue24325 — to implement most of types.coroutine in C to make it faster. I understand that yield-based coroutines can be confusing, but is this particular kind of confusion bad enough that if someone writes 'await fibonacci_generator()' we have to raise TypeError: object generator can't be used in 'await' expression instead of RuntimeError: Task got bad yield: 1? (that error message from asyncio could definitely be improved, but the fact that no one has improved it suggests that the problem isn't that severe) My goal here is to make it possible for Tornado applications running on 3.5 to use 'async def' and 'await' even though Tornado itself must remain compatible with 2.7 (as do many of the libraries that make up the Tornado ecosystem; I don't want libraries to have to update for compatibility with this feature). This is doable (I think) but non-trivial in the current design; making all generators awaitable would make it easier. I understand. My line of thoughts here is: we are introducing a new operator. However we define it now, will be set in stone after 3.5 is released. We should try to solve possible backwards compatibility issues without making its semantics less strict just to make things easier. Please take a look at the recently refactored types.coroutine (there is a link above). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Changes by koobs koobs.free...@gmail.com: -- nosy: +koobs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
koobs added the comment: We've (FreeBSD) seen and received several random and intermittent reports of failures during this stage of the build for all versions of Python, resulting in errors such as, among others: Parser/pgen.o: file not recognized: File truncated *** [Parser/pgen] Error code 1 pgenmain.c:(.text+0x258): undefined reference to `_Py_pgen' *** [Parser/pgen] Error code 1 1 error *** [Include/graminit.h] Error code 2 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200622 Given the existing patch breaks cross-builds, is there an alternative or safer way to make this section of the build more robust in order to make progress? -- versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24420] Documentation regressions from adding subprocess.run()
New submission from Martin Panter: After the documentation was rearranged by Issue 23342 (revision f0a00ee094ff), the “older high-level APIs” lost the paragraphs that said “The arguments shown above are merely the most common ones”. Given the limited signatures of call(), check_call() and check_output(), it is now too easy to assume that these functions do not accept the less-common Popen arguments. Also, in that issue I discovered an awkward edge case: there is actually no default value for the check_output() input parameter. Without an “input” parameter, the subprocess inherits its parent’s input, but input=None is equivalent to passing an empty string of the correct type. This patch hopefully fixes both problems. -- assignee: docs@python components: Documentation files: high-args.patch keywords: patch messages: 245111 nosy: docs@python, takluyver, vadmium priority: normal severity: normal status: open title: Documentation regressions from adding subprocess.run() type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39671/high-args.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Martin Panter added the comment: FWIW two times recently I saw strange intermittent build errors. I use “make -j2” on Linux. The one time that I investigated was a Python module (math or cmath perhaps?) failing to build because some dependency was zero bytes, and looking through the build log, I saw duplicate compiler commands lines printed out one after the other to build that dependency. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24420] Documentation regressions from adding subprocess.run()
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Ben Darnell added the comment: GeneratorWrapper helps, but it fails when applied to non-generator functions that return a value (while both tornado.gen.coroutine and asyncio.coroutine take pains to support such usage). The raise TypeError should be removed; just return the result without wrapping if it's not a generator. GeneratorWrapper also runs afoul of some places where I do explicit type checking instead of duck typing (isinstance(x, types.GeneratorType)). Using the Generator ABC doesn't work because the generator methods are set as attributes on __init__ instead of defined on the class. The methods should be defined on the class, even if they're overwritten with instance attributes later for speed. (related: inspect.iscoroutine is defined in terms of collections.abc.Coroutine. Should inspect.isgenerator be redefined to use the new collections.abc.Generator?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24413 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18003] lzma module very slow with line-oriented reading.
Martin Panter added the comment: The BufferedReader class is documented as being thread safe: https://docs.python.org/dev/library/io.html#multi-threading. Some experimentation suggests that checking the “raw.closed” property is not actually serialized, but that raw.readinto() calls are serialized. I don’t think this is a big problem in practice, so I think BZ2File would remain as thread-safe as BufferedReader is. But Serhiy’s point is definitely valid about the classes breaking the iterator protocol. FWIW I originally made this patch to satisfy my personal curiosity about why wrapping a second BufferedReader made things so much faster. Now I accept it is partly due to the overhead of the extra LZMAFile.readline() to BufferedReader.readline() delegation. Maybe it is not even worth optimizing around this kind of overhead, so I would even be happy to drop this patch and close the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Ben Darnell added the comment: On Tue, Jun 9, 2015 at 10:12 PM, Yury Selivanov rep...@bugs.python.org wrote: Yury Selivanov added the comment: All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: [..] Why is it anti-duck-typing? Awaitable is an object that implements __await__. With this patch coroutines are a separate type with __await__ (although, ceval doesn't use it to make things faster). Anti-duck-typing isn't quite the right word. What I meant was that Python 3.4 had generators that were used as coroutines. When we introduced __await__ in 3.5, we could have added __await__ as a method for all generators, since all generators have the necessary send/throw/close methods. But we didn't, and now we require an explicit marker that a given object was intended for a particular use instead of inferring that intention from the set of methods available. In asyncio we check for coroutine-ness only to raise errors if someone passes a wrong object, or to make @asyncio.coroutine work (which will go away eventually). The check for coroutine-ness is not just in asyncio; it happens in the core interpreter. Tornado has to adapt to this check in order to interoperate with 'async def' coroutines. Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type [..] Not sure what you mean here. It doesn't matter what callable is. It only matters if it returns a native coroutine, a generator-based coroutine, or an object with __await__. The type of the callable matters for the types.coroutine decorator. In order to get a coroutine object instead of a generator object, I must apply types.coroutine to the actual underlying generator, and not any wrapper. Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real. Well, 'await' expression is a new operator, and it makes total sense to limit its usage only to awaitables. Awaiting on a generator that yields a fibonacci sequence just doesn't make any sense, and *is* error prone. I think it would be a major mistake to allow this just to make things a little bit more convenient during the transition period. This particular patch does not divide generators in awaitables and non-awaitables, it introduces a new type for 'async def' coroutines. All confusion with old generator-based coroutines and @coroutine decorator is here only because we try to be backwards compatible; the compatibility layer can be removed in 3.7 or 3.8. There are three eras of coroutines to consider: 'async def' in 3.5+, 'yield from' in 3.3-3.4, and 'yield' in 2.5+. I'm trying to provide a path from 'yield' to 'async def'; this compatibility layer will remain relevant as long as people are migrating from 2.7. Was there a problem in practice with Python 3.4's asyncio in which people used yield from in a coroutine with generators that were intended to be iterators instead? Yes, a lot of people were confused where they have coroutines and where they have generators, and this was even mentioned in the Rationale section of the PEP. I understand that yield-based coroutines can be confusing, but is this particular kind of confusion bad enough that if someone writes 'await fibonacci_generator()' we have to raise TypeError: object generator can't be used in 'await' expression instead of RuntimeError: Task got bad yield: 1? (that error message from asyncio could definitely be improved, but the fact that no one has improved it suggests that the problem isn't that severe) My goal here is to make it possible for Tornado applications running on 3.5 to use 'async def' and 'await' even though Tornado itself must remain compatible with 2.7 (as do many of the libraries that make up the Tornado ecosystem; I don't want libraries to have to update for compatibility with this feature). This is doable (I think) but non-trivial in the current design; making all generators awaitable would make it easier. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: GeneratorWrapper helps, but it fails when applied to non-generator functions that return a value (while both tornado.gen.coroutine and asyncio.coroutine take pains to support such usage). The raise TypeError should be removed; just return the result without wrapping if it's not a generator. I think this is reasonable. I'll try it tomorrow to see if there are any corner cases, but I doubt there are any. GeneratorWrapper also runs afoul of some places where I do explicit type checking instead of duck typing (isinstance(x, types.GeneratorType)). Using the Generator ABC doesn't work because the generator methods are set as attributes on __init__ instead of defined on the class. The methods should be defined on the class, even if they're overwritten with instance attributes later for speed. Sure, this can be fixed too. Could you please update types.coroutine locally and verify that it will work for Tornado? (related: inspect.iscoroutine is defined in terms of collections.abc.Coroutine. Should inspect.isgenerator be redefined to use the new collections.abc.Generator?) Since abc.Generator is a new thing I guess we still can do that. Do you have a good use case for it? We need a good one to convince Larry to include this post-beta. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
