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

[Cesare Di Mauro]

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>