Re: [Python-Dev] Why aren't decorators just expressions?
I myself found out abotu this restriction once I clashesd into it- soit was one time the restriction bit me back. But I can't remember if that was for intended production code or for toying around either. Anyway, a simple "nop" function can allow for any arbitrary expression to be used as decorator, at expense of a little more line noise. And the restriction prevents the line noise to emerge as "cool" in some framework that mitg take inspiration in trends ongoing in other languages. nop = lambda f: f @nop(MyClass(things)[dimension1, dimension2[subdimension5]] + CombinableAutoMixinDecoFactory()) def my_func(): pass On 18 September 2017 at 18:33, Éric Araujo wrote: > Hello, > > Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit : >> 16.09.17 12:39, Larry Hastings пише: >>> So why don't decorators allow arbitrary expressions? [...] >> >> Actually I remember somebody raised this question a year or two ago,> but >> don't remember details. > > The discussion I remember was https://bugs.python.org/issue19660 > > Guido said: «Nobody has posted a real use case. All the examples are > toys. What are the real use cases that are blocked by this? Readability > counts!» > > Cheers > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br ___ 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] [RELEASE] Python 3.6.3rc1 and 3.7.0a1 are now available for testing and more
The Python build factories have been busy the last several weeks preparing our fall lineup of releases. Today we are happy to announce three additions: 3.6.3rc1, 3.7.0a1, and 3.3.7 final, which join last weekend's 2.7.14 and last month's 3.5.4 bug-fix releases and 3.4.7 security-fix update (https://www.python.org/downloads/). 1. Python 3.6.3rc1 is the first release candidate for Python 3.6.3, the next maintenance release of Python 3.6. While 3.6.3rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.3 is planned for final release on 2017-10-02 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.3rc1 and more information here: https://www.python.org/downloads/release/python-363rc1/ 2. Python 3.7.0a1 is the first of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.6.0a2, is planned for 2017-10-16. You can find Python 3.7.0a1 and more information here: https://www.python.org/downloads/release/python-370a1/ 3. Python 3.3.7 is also now available. It is a security-fix source-only release and is expected to be the final release of any kind for Python 3.3.x before it reaches end-of-life status on 2017-09-29, five years after its initial release. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail. If you are still using Python 3.3.x, we **strongly** encourage you to upgrade now to a more recent, fully supported version of Python 3. You can find Python 3.3.7 here: https://www.python.org/downloads/release/python-337/ -- Ned Deily [email protected] -- [] ___ 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] PEP 553, v3
Barry Warsaw wrote: > Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class > feature. I’ve also updated PR #3355 with the implementation to match. I've been in contact with Elizaveta Shashkova from JetBrains. She gave a great talk at Pycon 2017 which influenced my thinking about the feature that lead to PEP 553. https://www.youtube.com/watch?v=NdObDUbLjdg She wasn't able to post a follow up directly, but here is her response, pasted here with her permission. "In the beginning of 2017 we implemented frame evaluation debugger in the PyCharm IDE - the debugger, based on the frame evaluation API (included to Python 3.6 in PEP 523). This implementation improved debugger's performance significantly. The main idea of this debugger is using custom frame evaluation function for implementing breakpoints instead of standard tracing function. In fact, before the entering a new frame we're modifying the code object, generated for this frame and we're inserting breakpoints right into the code object. At the moment we're doing quite complicated things: we define our own local `breakpoint()` function (which leads debugger to a suspend state), create a wrapper for it, and insert the wrapper's code into the user's code. In order to be able to call this function, we add it to frame's globals dict. It's a bit tricky and it still has some problems. So if PEP 553 is accepted, it will help us to make this part of the debugger much simpler: we will be able to specify our breakpoint function for the whole program and call built-in breakpoint() function instead of all these manipulations with wrappers and frame's globals. It will make our frame evaluation debugger less complicated and more stable." Cheers, -Barry ___ 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
