[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20 (original) (raw)

Cesare Di Mauro cesare.di.mauro at gmail.com
Sat Apr 28 02:32:20 EDT 2018

Hi,

2018-04-28 5:08 GMT+02:00 Armin Rigo <armin.rigo at gmail.com>:

Hi,

On 26 April 2018 at 07:50, Raymond Hettinger <raymond.hettinger at gmail.com> wrote: >> [Raymond Hettinger <raymond.hettinger at gmail.com>] >>> After re-reading all the proposed code samples, I believe that >>> adopting the PEP will make the language harder to teach to people >>> who are not already software engineers. > > (...) > > Python is special, in part, because it is not one of those languages. > It has virtues that make it suitable even for elementary school children. > We can show well-written Python code to non-computer folks and walk > them through what it does without their brains melting (something I can't > do with many of the other languages I've used). There is a virtue > in encouraging simple statements that read like English sentences > organized into English-like paragraphs, presenting itself like > "executable pseudocode". I must admit that when I heard about this PEP I thought "this April 1st joke was already done long ago". I'm sorry to discover that, this time, it is not actually one. Thank you, Raymond, for an unlikely attempt at reminding people what made Python so special---in your opinion, and mine.

A bientôt, Armin.

Same feeling here. What I really appreciate of Python from long time is its readability: the fact that usually I read the code as English-like sentences.

It was nice to see the usage of the "as" keyword in the try/except construct as well as in the with one, instead of introducing another bunch of symbols which will make it more difficult to decode the meaning of the writing. Same for the "if/else" ternary operator, which I read like "[give] x if cond else y", instead of the cryptic "?:" of C-like languages. It was a nice and wise design decision.

For similar reasons, I did/don't like the @ for matrix multiplication because it doesn't give me any immediately, useful information which makes it easier to decode the meaning. A "mul" binary operator would have worked better, for example.

I hope that Python core developers refuse the temptation to introduce new operators using symbols for new features: it's a short way to keep backward-compatibility, for sure, but if the price to pay is the readability, then I don't think that it's worth to do it.

Regarding the assignment operator, I also find it a (bad, since it's not so much readable inside expressions) duplicate of the assignment statement. To be more precise, why should we keep the latter once with the former we can do the same things (and more)? Then drop the assignment statement and just leave the operator!

BTW, as a pythonist I've also felt the need to have some way to "bind" values to variables in some context, but it's pretty much related to comprehensions, for obvious reasons I think. I would have appreciated an "as" keyword, only inside such constructs, but I don't see any value extending it for any generic context, since we already have the assignment statement which works quite well and doesn't introduce nasty side-effects "ala C-like languages". So, IMO it's better to stay as we are instead of introducing another kludge to the language, if we cannot maintain a good readability.

Cheers,

Cesare -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180428/914fd4d2/attachment.html>

More information about the Python-Dev mailing list