[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-12-02 - 2016-12-09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5621 ( +8) closed 35057 (+55) total 40678 (+63) Open issues with patches: 2440 Issues opened (40) == #28864: Add devnull file-like object http://bugs.python.org/issue28864 opened by rhettinger #28866: Type cache is not correctly invalidated on a class defining mr http://bugs.python.org/issue28866 opened by sjpalt #28867: NamedTemporaryFile does not generate a ResourceWarning for unc http://bugs.python.org/issue28867 opened by jdufresne #28869: __module__ attribute is not set correctly for a class created http://bugs.python.org/issue28869 opened by levkivskyi #28870: Refactor PyObject_CallFunctionObjArgs() and like http://bugs.python.org/issue28870 opened by serhiy.storchaka #28871: Destructor of ElementTree.Element is recursive http://bugs.python.org/issue28871 opened by serhiy.storchaka #28874: test_logging fails and freezes http://bugs.python.org/issue28874 opened by Whitequill Riclo #28876: bool of large range raises OverflowError http://bugs.python.org/issue28876 opened by mark.dickinson #28877: Cannot compile _ssl.o on HP-UX http://bugs.python.org/issue28877 opened by James Matthews #28879: smtplib send_message should add Date header if it is missing, http://bugs.python.org/issue28879 opened by Henning.von.Bargen #28881: int no attribute 'lower' iterating email.Message http://bugs.python.org/issue28881 opened by Vitold S #28882: RFC: Slice confusing with negative strides and the 0th element http://bugs.python.org/issue28882 opened by hardkrash #28883: Python 3.5.2 crashers (from PyPy) http://bugs.python.org/issue28883 opened by arigo #28884: Python 3.5.2 non-segfaulting bugs (from PyPy) http://bugs.python.org/issue28884 opened by arigo #28885: Python 3.5.2 strange-behavior issues (from PyPy) http://bugs.python.org/issue28885 opened by arigo #28886: Move deprecated abc module decorators to separate section in d http://bugs.python.org/issue28886 opened by John Hagen #2: Installer fails when newer version of CRT is pending installat http://bugs.python.org/issue2 opened by steve.dower #28889: IDLE needs the ability to pass in command-line arguments http://bugs.python.org/issue28889 opened by rhettinger #28890: logging.handlers: Document that QueueListener is a daemon thre http://bugs.python.org/issue28890 opened by Julien Castiaux #28891: Standardise more behaviours for zero-argument super() __class_ http://bugs.python.org/issue28891 opened by ncoghlan #28893: Make sure exceptions raised in __aiter__ are properly chained http://bugs.python.org/issue28893 opened by yselivanov #28895: Two suggestions for windows.html http://bugs.python.org/issue28895 opened by mark #28896: Embeddable zip allows Windows registry to override module loca http://bugs.python.org/issue28896 opened by izbyshev #28898: Can't compile gdb with Python 3.6 http://bugs.python.org/issue28898 opened by cstratak #28900: update 'docs for other versions' http://bugs.python.org/issue28900 opened by Matthias v/d Meent #28901: Windows: document that site is not imported by default by embe http://bugs.python.org/issue28901 opened by Matthias v/d Meent #28902: 3.6.0rc1 installer fails to install / uninstall. http://bugs.python.org/issue28902 opened by Decorater #28907: test_pydoc fails if build is in sub-directory http://bugs.python.org/issue28907 opened by nascheme #28908: pydoc getdocloc() is broken http://bugs.python.org/issue28908 opened by nascheme #28909: Adding LTTng-UST tracing support http://bugs.python.org/issue28909 opened by Francis Deslauriers #28911: Clarify the behaviour of assert_called_once_with http://bugs.python.org/issue28911 opened by 153957 #28912: collections.abc.OrderedMapping http://bugs.python.org/issue28912 opened by jab #28913: "Fatal Python error: Cannot recover from stack overflow." from http://bugs.python.org/issue28913 opened by Richard Eames #28914: selectmodule build fails http://bugs.python.org/issue28914 opened by sxsns243 #28916: Not matched behavior of modulo operator % with the description http://bugs.python.org/issue28916 opened by woo yoo #28918: cross compiling xxlimited fails with "Py_LIMITED_API is incomp http://bugs.python.org/issue28918 opened by xdegaye #28919: Simplify `_copy_func_details` in unittest.mock http://bugs.python.org/issue28919 opened by Jiajun Huang #28920: Dangerous usage of "O" format string in _asynciomodule.c http://bugs.python.org/issue28920 opened by haypo #28921: Make str.count one character for latin1 string faster http://bugs.python.org/issue28921 opened by xiang.zhang #28922: Add fixer for "import exceptions" http://bugs.python.org/issue28922 opened by Valentin.Lorentz Most recent 15 issues with no replies (15) ===
[Python-Dev] PyObject_CallFunction(func, "O", arg) special case
Hi, The PyObject_CallFunction() function has a special case when the format string is "O", to pass exactly one Python object: * If the argument is a tuple, the tuple is unpacked: it behaves like func(*arg) * Otherwise, it behaves like func(arg) This case is not documented in the C API ! https://docs.python.org/dev/c-api/object.html#c.PyObject_CallFunction The following C functions have the special case: * PyObject_CallFunction(), _PyObject_CallFunction_SizeT() * PyObject_CallMethod(), _PyObject_CallMethod_SizeT() * _PyObject_CallMethodId(), _PyObject_CallMethodId_SizeT() I guess that it's a side effect of the implementation: the code uses Py_BuildValue() and then checks if the value is a tuple or not. Py_BuildValue() is a little bit surprising: * "i" creates an integer object * "ii" creates a tuple * "(i)" and "(ii)" create a tuple. Getting a tuple or not depends on the length of the format string. It is not obvious when you have nested tuples like "O(OO)". Because of the special case, passing a tuple as the only argument requires to write "((...))" instead of just "(...)". In the past, this special behaviour caused a bug in generator.send(arg), probably because the author of the C code implementing generator.send() wasn't aware of the special case. See the issue: http://bugs.python.org/issue21209 I found code using "O" format in the new _asyncio module, and I'm quite sure that unpacking special case is not expected. So I opened an issue: http://bugs.python.org/issue28920 Last days, I patched functions of PyObject_CallFunction() family to use internally fast calls. I implemented the special case to keep backward compatibility. I replaced a lot of code using PyObject_CallFunction() with PyObject_CallFunctionObjArgs() when the format string was only made of "O", PyObject* arguments. I made this change to optimize the code, but indirectly, it avoids also the special case for code which used exactly "O" format. See: http://bugs.python.org/issue28915 When I made these changes, I found some functions which rely the unpacking feature! * time_strptime() (change 49a7fdc0d40a) * unpickle() of _ctypes (change ceb22b8f6d32) I don't know well what we are supposed to do. I don't think that changing the behaviour of PyObject_CallFunction() to remove the special case is a good idea. It would be an obvious backward incompatible change which can break applications. I guess that the minimum is to document the special case? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
2016-12-09 18:46 GMT+01:00 Victor Stinner : > Last days, I patched functions of PyObject_CallFunction() family to > use internally fast calls. > (...) > http://bugs.python.org/issue28915 Oh, I forgot to mention the performance results of these changes. Python slots are now a little bit faster. Extract of the issue: http://bugs.python.org/issue28915#msg282748 Microbenchmark on a simple class with an __int__() method, call int(o): int(o): Median +- std dev: [ref] 239 ns +- 13 ns -> [patch] 219 ns +- 14 ns: 1.10x faster (-9%) Microbenchmark on a simple class with an __getitem__() method, call o[100]: o[100]: Median +- std dev: [ref] 211 ns +- 11 ns -> [patch] 172 ns +- 11 ns: 1.23x faster (-19%) Comparison between Python 2.7, 3.5, 3.7 and 3.7+patch, 3.5 is used as the reference: int(o) == Median +- std dev: [3.5] 271 ns +- 15 ns -> [3.7] 239 ns +- 13 ns: 1.13x faster (-12%) Median +- std dev: [3.5] 271 ns +- 15 ns -> [patch] 219 ns +- 14 ns: 1.24x faster (-19%) Median +- std dev: [3.5] 271 ns +- 15 ns -> [2.7] 401 ns +- 21 ns: 1.48x slower (+48%) o[100] == Median +- std dev: [3.5] 206 ns +- 5 ns -> [3.7] 211 ns +- 11 ns: 1.02x slower (+2%) Not significant! Median +- std dev: [3.5] 206 ns +- 5 ns -> [patch] 172 ns +- 11 ns: 1.20x faster (-17%) Median +- std dev: [3.5] 206 ns +- 5 ns -> [2.7] 254 ns +- 15 ns: 1.23x slower (+23%) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Checking over the devguide before the GitHub migration
With Python 3.6.0 quickly approaching it means the GitHub migration should also be happening sometime soon (basically as soon as all pieces are in place and we're sure we won't be doing an emergency 3.6.1 release, so probably either this month or next). While we wait for that to occur, if people want to help then please read through the GitHub version of the devguide at http://cpython-devguide.readthedocs.io/en/github/ and if you find any issues then please submit a PR at https://github.com/python/devguide. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New core-workflow issue tracker
I have created https://github.com/python/core-workflow to track plans and ideas for our workflow. Discussions will continue on the core-workflow mailing list, but since there are things to plan and this sort of thing doesn't really belong on bugs.python.org I figured a separate tracker would be best. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Someons's put a "Python 2.8" on GitHub
"Python 2.8 is a backwards-compatible Python interpreter with new features from Python 3.x. It was produced by forking Python 2.7.12 and backporting some of the new syntax, builtins, and libraries from Python 3. Python code and C-extensions targeting Python 2.7 or below are expected to run unmodified on Python 2.8 and produce the same output. But with Python 2.8, that code can now use some of the new features from Python 3.x." Backported features: * Function annotations * Keyword-only arguments * async / await * no-argument super() * new metaclass syntax * yield from * typing module * inspect.signature() * matrix multiplication operator * fine-grained reworking of OSError * underscores in numeric literals * concurrent.futures * types.MappingProxyType * selectors module https://github.com/naftaliharris/python2.8 Huh, //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
On 09.12.16 19:46, Victor Stinner wrote: The PyObject_CallFunction() function has a special case when the format string is "O", to pass exactly one Python object: * If the argument is a tuple, the tuple is unpacked: it behaves like func(*arg) * Otherwise, it behaves like func(arg) This case is not documented in the C API ! https://docs.python.org/dev/c-api/object.html#c.PyObject_CallFunction It is documented for Py_BuildValue(), and the documentation of PyObject_CallFunction() refers to Py_BuildValue(). I just found that in spite of your changes of parameter names, the documentation still have old names: PyObject* PyObject_CallMethod(PyObject *o, const char *method, const char *format, ...) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
On 09.12.16 19:46, Victor Stinner wrote: Last days, I patched functions of PyObject_CallFunction() family to use internally fast calls. I implemented the special case to keep backward compatibility. I replaced a lot of code using PyObject_CallFunction() with PyObject_CallFunctionObjArgs() when the format string was only made of "O", PyObject* arguments. I made this change to optimize the code, but indirectly, it avoids also the special case for code which used exactly "O" format. See: http://bugs.python.org/issue28915 I didn't have a change to make a review of your patches, because they were pushed 7 minutes after publishing a patch. I'm still in the process of post-commit reviewing. Could you please give more time for pre-commit review? I thought about similar changes, but since I didn't have evidences that they cause performance gain, I dropped my patches. Do you have benchmark results that proof the speed up for all your changes? Did you checked that your changes do not increase C stack consumption? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
On 10 December 2016 at 15:56, Larry Hastings wrote: > > "Python 2.8 is a backwards-compatible Python interpreter with new features > from Python 3.x. It was produced by forking Python 2.7.12 and backporting > some of the new syntax, builtins, and libraries from Python 3. Python code > and C-extensions targeting Python 2.7 or below are expected to run > unmodified on Python 2.8 and produce the same output. But with Python 2.8, > that code can now use some of the new features from Python 3.x." > > Backported features: > > Function annotations > Keyword-only arguments > async / await > no-argument super() > new metaclass syntax > yield from > typing module > inspect.signature() > matrix multiplication operator > fine-grained reworking of OSError > underscores in numeric literals > concurrent.futures > types.MappingProxyType > selectors module > > https://github.com/naftaliharris/python2.8 Aye, I saw that recently in an Infoworld article. One area where this could be particularly interesting is for folks embedding Python in larger commercial applications (ArcGIS, Maya, etc) that already build their own Python from source with the same C/C++ compiler that they use to build the rest of the application (so arbitrary Python C extensions aren't supported). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
