[Python-Dev] PEP 572: Do we really need a ":" in ":="?

[Alexander Belopolsky]

On Thu, Jul 5, 2018 at 8:28 PM Tim Peters <tim.peters at gmail.com> wrote:

> [Alexander Belopolsky]
> > ...
> >  I also think that the dreadfulness of mistyping = where == is expected
> >  is exaggerated.
>
> There are a number of core devs who would be rabidly opposed to allowing
> that confusion in Python, due to still-remembered real-life nightmares in
> C.  For example, me ;-)  It only takes one wasted day of debugging that
> typo in a time-critical project to sour you on it for life, and several of
> us run out of fingers counting the number of days it actually did cost over
> our C careers.
>

I still do quite a bit of C programming and I have exactly the opposite
experience given modern environments: why is gcc/clang/vs complaining about
if (x=a) - I know what I am doing!  No, I don't want to put two pairs of
(..) around condition - one is one too many!



> Alas, many people new to Python put parens around _all_ `if` and `while`
> conditions, due to habit carried over from other languages (common as
> newbies on, e.g., StackOverflow).  They're the most vulnerable.  Nobody in
> their right mind even suspects that putting parens around an entire
> expression could have semantic significance.
>
>     a = 1 + 2  # OK, adds 1 and 2
>     a = (1 + 2) # but who could possibly guess what this means? ;-)
>
> But I expect the idea was DOA for the first reason above.
>

Not that unlike Yuri, I don't think the language should require (..) around
assignment expressions.

Seriously, ':=' looks like a reluctantly introduced kludge to allow
assignment in expressions.  We agree that it is sometimes useful to have,
but we will make the feature really hard to use or discover.  What happened
to the "consenting adults" philosophy?  Do we want to protect users who
cannot tell = from == so much that  we are willing to cause Python to be
the first language with two non-interchangeable assignment operators?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/2055aded/attachment-0001.html>