Not really related but the PEP says that arguments in Python are evaluated
before the function (as a reason to reject the idea of None-aware function
call) but this is not the case:
>>> import dis
>>> dis.dis(lambda : f()(g()))
1 0 LOAD_GLOBAL 0 (f)
3 CALL_FUNCTION 0
6 LOAD_GLOBAL 1 (g)
9 CALL_FUNCTION 0
12 CALL_FUNCTION 1
15 RETURN_VALUE
Andrea
On Wed, Nov 29, 2017 at 7:14 PM, Joao S. O. Bueno
On Nov 28, 2017, at 15:31, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
Put me down for a strong -1. The proposal would occasionally save a few keystokes but comes at the expense of giving Python a more Perlish look and a more arcane feel.
I am also -1.
One of the things I like about Python is that I can walk non-programmers through the code and explain what it does. The examples in PEP 505 look like a step in the wrong direction. They don't "look like Python" and make me feel like I have to decrypt the code to figure-out what it does.
I had occasional to speak with someone very involved in Rust development. They have a process roughly similar to our PEPs. One of the
On 28 November 2017 at 18:38, Barry Warsaw
wrote: things he told me, which I found very interesting and have been mulling over for PEPs is, they require a section in their specification discussion how any new feature will be taught, both to new Rust programmers and experienced ones. I love the emphasis on teachability. Sometimes I really miss that when considering some of the PEPs and the features they introduce (look how hard it is to teach asynchronous programming). Oh well, I would be +1 on patching PEP 1 for that.
Cheers, -Barry
_______________________________________________ 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/ agriff%40tin.it