[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

[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.

>  In all motivating cases, := is used to introduce new bindings rather than
> rebinding existing names.

I've heard people say that several times now, but suspect that's due to
that they're looking at "motivating cases" in isolation.  In a function,
for example, doing a lot with regexps, blocks like

    if m := pat1.search(string):

    if m := pat2.search(substring):

may be present any number of times.  Only the first such block is _not_ a
rebinding.  Reusing short temp names for stuff like this may be almost as
common as using `i` and `j` as for-loop target names.

>  Automated code checkers can easily warn users when they rebind
> variables in if statements and suggest that they silence the warnings
> with redundant (..) if they really want what they wrote.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/56e0d007/attachment.html>