[Python-Dev] __signature__ for PySide ready
Hi friends, in the last months, I have developed signature support for PySide. The module creates the same signatures as are known for plain Python functions. As a non-trivial addition, the module also handles multiple signatures as a list. I consider this extension to PySide as quite essential and actually more important as for Python itself, because type info is rather crucial for PySide. Initially, I wrote this as a pure Python 3 extension. Then I was "asked" to port this to Python 2 too, which was quite hairy to do. I'm not sure if I should have done that. Before I publish this module, I want to ask: Is it a bad idea to support signatures in Python 2 as well? Do I introduce a feature that should not exist in Python 2? Or is it fine to do so? Please let me know your opinion, I am happy with any result. Cheers -- Chris -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Could someone review GH-2974 which add missing PyObject_GC_UnTrack()?
Hi. I created PR which fixes potential crash. Serhiy Storchaka approved it already, but he wants one other review from core dev. And I updated document after his review too. So I want more one reviewer for the PR. Someone help me? https://github.com/python/cpython/pull/2974 https://bugs.python.org/issue31095 ## Background For GC types, tp_dealloc should call PyObject_GC_UnTrack() before calling any APIs which can run arbitrary code, including Py_DECREF. Without calling it, GC may happen during tp_dealloc and GC will find object which refcnt == 0. I checked all GC types and find some unsafe tp_dealloc. Even "extending and embedding" document missed untracking. Regards, INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2017-08-11 - 2017-08-18) 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: open6133 (+17) closed 36852 (+32) total 42985 (+49) Open issues with patches: 2343 Issues opened (35) == #14976: queue.Queue() is not reentrant, so signals and GC can cause de http://bugs.python.org/issue14976 reopened by yselivanov #30747: _Py_atomic_* not actually atomic on Windows with MSVC http://bugs.python.org/issue30747 reopened by steve.dower #30983: eval frame rename in pep 0523 broke gdb's python extension http://bugs.python.org/issue30983 reopened by haypo #31170: expat: utf8_toUtf8 cannot properly handle exhausting buffer http://bugs.python.org/issue31170 reopened by tianlynn #31184: Fix data descriptor detection in inspect.getattr_static http://bugs.python.org/issue31184 opened by davidhalter #31185: Miscellaneous errors in asyncio speedup module http://bugs.python.org/issue31185 opened by serhiy.storchaka #31188: Makefile.pre.in: commoninstall: reformat http://bugs.python.org/issue31188 opened by dilyan.palauzov #31189: README.rst: installing multiple versions: typo http://bugs.python.org/issue31189 opened by dilyan.palauzov #31190: ./configure: add ability to build and install only shared libr http://bugs.python.org/issue31190 opened by dilyan.palauzov #31191: Fix grammar in threading.Barrier docs http://bugs.python.org/issue31191 opened by schedutron #31193: re.IGNORECASE strips combining character from lower case of LA http://bugs.python.org/issue31193 opened by David MacIver #31196: Blank line inconsistency between InteractiveConsole and standa http://bugs.python.org/issue31196 opened by Malcolm Smith #31197: Namespace disassembly omits some compiled objects http://bugs.python.org/issue31197 opened by ncoghlan #31199: configure checks fail confusingly under --with-address-sanitiz http://bugs.python.org/issue31199 opened by pmatos #31200: address sanitizer build fails http://bugs.python.org/issue31200 opened by pmatos #31201: module test that failed doesn't exist http://bugs.python.org/issue31201 opened by pmatos #31202: Windows pathlib.Path.glob(pattern) fixed part of the pattern c http://bugs.python.org/issue31202 opened by aicirbs #31203: socket.IP_PKTINFO is missing from python http://bugs.python.org/issue31203 opened by guerby #31206: IDLE, configdialog: Factor out HighPage class from ConfigDialo http://bugs.python.org/issue31206 opened by terry.reedy #31207: IDLE, configdialog: Factor out ExtPage class from ConfigDialog http://bugs.python.org/issue31207 opened by terry.reedy #31209: MappingProxyType can not be pickled http://bugs.python.org/issue31209 opened by Alex Hayes #31210: Can not import modules if sys.prefix contains DELIM http://bugs.python.org/issue31210 opened by ced #31211: distutils/util.py get_platform() does not identify linux-i686 http://bugs.python.org/issue31211 opened by siming85 #31212: datetime: min date (0001-01-01 00:00:00) can't be converted to http://bugs.python.org/issue31212 opened by Dave Johansen #31213: __context__ reset to None in nested exception http://bugs.python.org/issue31213 opened by Christopher Stelma #31215: Add version changed notes for OpenSSL 1.1.0 compatibility http://bugs.python.org/issue31215 opened by ncoghlan #31217: test_code leaked [1, 1, 1] memory blocks on x86 Gentoo Refleak http://bugs.python.org/issue31217 opened by haypo #31218: del expects __delitem__ if __setitem__ is defined http://bugs.python.org/issue31218 opened by raumzeitkeks #31222: datetime.py implementation of .replace inconsistent with C imp http://bugs.python.org/issue31222 opened by p-ganssle #31224: Missing definition of frozen module http://bugs.python.org/issue31224 opened by marco.buttu #31226: shutil.rmtree fails when target has an internal directory junc http://bugs.python.org/issue31226 opened by vidartf #31227: regrtest: reseed random with the same seed before running a te http://bugs.python.org/issue31227 opened by haypo #31229: wrong error messages when too many kwargs are received http://bugs.python.org/issue31229 opened by Oren Milman #31230: Define a general "asynchronous operation introspection" protoc http://bugs.python.org/issue31230 opened by ncoghlan #31232: Backport the new custom "print >> sys.stderr" error message? http://bugs.python.org/issue31232 opened by ncoghlan Most recent 15 issues with no replies (15) == #31224: Missing definition of frozen module http://bugs.python.org/issue31224 #31207: IDLE, configdialog: Factor out ExtPage class from ConfigDialog http://bugs.python.org/issue31207 #31202: Windows pathlib.Path.glob(pattern) fixed part of the pattern c http://bugs.python.org/issue31202 #31196: Blank line inconsistency between InteractiveConsole and standa http://bugs.python.
Re: [Python-Dev] __signature__ for PySide ready
Hi Christian, On Fri, Aug 18, 2017 at 4:41 AM, Christian Tismer wrote: > Hi friends, > > in the last months, I have developed signature support for > PySide. The module creates the same signatures as are known > for plain Python functions. > > As a non-trivial addition, the module also handles multiple > signatures as a list. I consider this extension to PySide > as quite essential and actually more important as for Python > itself, because type info is rather crucial for PySide. > > Initially, I wrote this as a pure Python 3 extension. > Then I was "asked" to port this to Python 2 too, which was > quite hairy to do. I'm not sure if I should have done that. > > Before I publish this module, I want to ask: > > > Is it a bad idea to support signatures in Python 2 as well? There's a backport of signature API to Python 2. Although last time I checked it was fairly outdated. > Do I introduce a feature that should not exist in Python 2? > Or is it fine to do so? > > Please let me know your opinion, I am happy with any result. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __signature__ for PySide ready
On Fri, 18 Aug 2017 at 02:05 Christian Tismer wrote: > Hi friends, > > in the last months, I have developed signature support for > PySide. The module creates the same signatures as are known > for plain Python functions. > > As a non-trivial addition, the module also handles multiple > signatures as a list. I consider this extension to PySide > as quite essential and actually more important as for Python > itself, because type info is rather crucial for PySide. > > Initially, I wrote this as a pure Python 3 extension. > Then I was "asked" to port this to Python 2 too, which was > quite hairy to do. I'm not sure if I should have done that. > > Before I publish this module, I want to ask: > > > Is it a bad idea to support signatures in Python 2 as well? > Do I introduce a feature that should not exist in Python 2? > Or is it fine to do so? > > Please let me know your opinion, I am happy with any result. > If you're getting paid to do the port then I don't think it really hurts anything since it isn't going to magically open Python 2 to more usage. In fact, if you are filling in the annotation information so that type hints are being exposed then maybe there's a chance it might help someone port to Python 3? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbot report, August 2017
Hi, Here is a quick report of what changed recently on buildbots. == pythoninfo == I added a new "python3 -m test.pythoninfo" command which is now run on Travis CI, AppVeyor and buildbots. https://bugs.python.org/issue30871 This command dumps various informations to help debugging test failures on our CIs. For example, you get the Tcl version, information about the threading implementation, etc. Currently, pythoninfo is only run on the master branch, but I plan to run it on Python 3.6 and 2.7 later. The pythoninfo idea comes from https://bugs.python.org/issue29854 when we didn't know the readline version of a buildbot, and I didn't want to put such information in regrtest header, since importing readline has side effects. == Removed buildbots == A few buildbots were removed: * All Python 3.5 buildbots was removed, since the 3.5 branch entered the security only stage: https://mail.python.org/pipermail/python-dev/2017-August/148794.html * FreeBSD 9-STABLE (koobs-freebsd9): FreeBSD 9 is no more supported upstream, use FreeBSD 10 and FreeBSD CURRENT buildbots * OpenIndiana: was offline since the beginning of June. Previous discussions on this list: * September 2016: OpenIndiana and Solaris support https://mail.python.org/pipermail/python-dev/2016-September/146538.html * April 2015: MemoryError and other bugs on AMD64 OpenIndiana 3.x https://mail.python.org/pipermail/python-dev/2015-April/138967.html * September 2014: Sad status of Python 3.x buildbots https://mail.python.org/pipermail/python-dev/2014-September/136175.html * intel-ubuntu-skylake: Florin Papa wrote me that the machine became unavailable in December 2016. * Yosemite ICC buildbot (intel-yosemite-icc): it was maintained by Zachary Ware and R. David Murray. Sadly, David lost the VM image to a disk crash :-( New ICC buildbots may come back later, wait & see ;-) * macOS Snow Leopard (murray-snowleopard): this old machine was stuck at boot for an unknown reason. "It's an old machine, and it is probably time to get rid of it." wrote R. David Murray :-) == Reduced failure rate == As usual, many race conditions were fixed in tests and in the code, to reduce the buildbot failure rate. I may list them in a blog post, later. == What's Next? == * Buildbot should be upgrade to buildbot 0.9: https://github.com/python/buildmaster-config/pull/12 * Zachary Ware plans to rewrite our buildbot configuration during the CPython sprint (Sept 4-9) * test_logging fails randomly on FreeBSD 10 with a warning related to threads (bpo-30830). I was trying to reproduce the bug since 2 months. I just identified to root bug! https://bugs.python.org/issue31233 "socketserver.ThreadingMixIn leaks running threads after server_close()". * The "Docs" buildbot (currently offline) may be dropped as well, https://github.com/python/buildmaster-config/pull/21 See also my previous buildbot report: https://haypo.github.io/python-buildbots-2017q2.html Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] socketserver ForkingMixin waiting for child processes
2017-08-12 0:34 GMT+02:00 Ryan Smith-Roberts : > Since ThreadingMixIn also leaks threads, > server_close() could grow a timeout flag (following the socket module > timeout convention) and maybe a terminate boolean. ThreadingMixIn could then > also be fixed. I'm not sure how useful that is though, since I'd bet almost > all users of socketserver exit the process shortly after server_close(). > Plus it can't be backported to the feature-freeze branches. Oh. It took me 2 months, but I finally identified why *sometimes*, test_logging fails with warning about threads. It's exactly because of the weak socketserver.ThreadingMixIn which leaves running threads in the background, even after server_close(). I just opened a new issue: "socketserver.ThreadingMixIn leaks running threads after server_close()" https://bugs.python.org/issue31233 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __signature__ for PySide ready
2017-08-18 18:20 GMT+02:00 Yury Selivanov : > Hi Christian, > > On Fri, Aug 18, 2017 at 4:41 AM, Christian Tismer > wrote: > > Hi friends, > > > > in the last months, I have developed signature support for > > PySide. The module creates the same signatures as are known > > for plain Python functions. > > > > As a non-trivial addition, the module also handles multiple > > signatures as a list. I consider this extension to PySide > > as quite essential and actually more important as for Python > > itself, because type info is rather crucial for PySide. > > > > Initially, I wrote this as a pure Python 3 extension. > > Then I was "asked" to port this to Python 2 too, which was > > quite hairy to do. I'm not sure if I should have done that. > > > > Before I publish this module, I want to ask: > > > > > > Is it a bad idea to support signatures in Python 2 as well? > > There's a backport of signature API to Python 2. Although last time I > checked it was fairly outdated. > > I wrote a backport earlier this year: https://pypi.python.org/pypi/inspect2. > > Do I introduce a feature that should not exist in Python 2? > > Or is it fine to do so? > > > > Please let me know your opinion, I am happy with any result. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > jelle.zijlstra%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 550 v3
Hi, This is a third iteration of the PEP. There was some really good feedback on python-ideas and the discussion thread became hard to follow again, so I decided to update the PEP only three days after I published the previous version. Summary of the changes can be found in the "Version History" section: https://www.python.org/dev/peps/pep-0550/#version-history There are a few open questions left, namely the terminology and design of ContextKey API. On the former topic, I'm quite happy with the latest version: Execution Context, Logical Context, and Context Key. Thank you, Yury PEP: 550 Title: Execution Context Version: $Revision$ Last-Modified: $Date$ Author: Yury Selivanov Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Aug-2017 Python-Version: 3.7 Post-History: 11-Aug-2017, 15-Aug-2017, 18-Aug-2017 Abstract This PEP proposes a new mechanism to manage execution state--the logical environment in which a function, a thread, a generator, or a coroutine executes in. A few examples of where having a reliable state storage is required: * Context managers like decimal contexts, ``numpy.errstate``, and ``warnings.catch_warnings``; * Storing request-related data such as security tokens and request data in web applications, implementing i18n; * Profiling, tracing, and logging in complex and large code bases. The usual solution for storing state is to use a Thread-local Storage (TLS), implemented in the standard library as ``threading.local()``. Unfortunately, TLS does not work for the purpose of state isolation for generators or asynchronous code, because such code executes concurrently in a single thread. Rationale = Traditionally, a Thread-local Storage (TLS) is used for storing the state. However, the major flaw of using the TLS is that it works only for multi-threaded code. It is not possible to reliably contain the state within a generator or a coroutine. For example, consider the following generator:: def calculate(precision, ...): with decimal.localcontext() as ctx: # Set the precision for decimal calculations # inside this block ctx.prec = precision yield calculate_something() yield calculate_something_else() Decimal context is using a TLS to store the state, and because TLS is not aware of generators, the state can leak. If a user iterates over the ``calculate()`` generator with different precisions one by one using a ``zip()`` built-in, the above code will not work correctly. For example:: g1 = calculate(precision=100) g2 = calculate(precision=50) items = list(zip(g1, g2)) # items[0] will be a tuple of: # first value from g1 calculated with 100 precision, # first value from g2 calculated with 50 precision. # # items[1] will be a tuple of: # second value from g1 calculated with 50 precision (!!!), # second value from g2 calculated with 50 precision. An even scarier example would be using decimals to represent money in an async/await application: decimal calculations can suddenly lose precision in the middle of processing a request. Currently, bugs like this are extremely hard to find and fix. Another common need for web applications is to have access to the current request object, or security context, or, simply, the request URL for logging or submitting performance tracing data:: async def handle_http_request(request): context.current_http_request = request await ... # Invoke your framework code, render templates, # make DB queries, etc, and use the global # 'current_http_request' in that code. # This isn't currently possible to do reliably # in asyncio out of the box. These examples are just a few out of many, where a reliable way to store context data is absolutely needed. The inability to use TLS for asynchronous code has lead to proliferation of ad-hoc solutions, which are limited in scope and do not support all required use cases. Current status quo is that any library, including the standard library, that uses a TLS, will likely not work as expected in asynchronous code or with generators (see [3]_ as an example issue.) Some languages that have coroutines or generators recommend to manually pass a ``context`` object to every function, see [1]_ describing the pattern for Go. This approach, however, has limited use for Python, where we have a huge ecosystem that was built to work with a TLS-like context. Moreover, passing the context explicitly does not work at all for libraries like ``decimal`` or ``numpy``, which use operator overloading. .NET runtime, which has support for async/await, has a generic solution of this problem, called ``ExecutionContext`` (see [2]_). On the surface, working with it is very similar to working with a TLS, but the former explicitly supports asynchronous code. Goals = The goal of this PEP is to provi
