[Python-ideas] PEP 572: Assignment Expressions (post #4)

[Guido van Rossum]

On Fri, Apr 13, 2018 at 7:36 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 April 2018 at 22:35, Chris Angelico <rosuav at gmail.com> wrote:
> > The 'as' syntax already has that going for it. What's the advantage of
> > the arrow over the two front-runners, ':=' and 'as'?
>
> I stumbled across
> https://www.hillelwayne.com/post/equals-as-assignment/ earlier this
> week, and I think it provides grounds to reconsider the suitability of
> ":=", as that symbol has historically referred to *re*binding an
> already declared name. That isn't the way we're proposing to use it
> here: we're using it to mean both implicit local variable declaration
> *and* rebinding of an existing name, the same as we do for "=" and
> "as".
>

I've not done much research about this topic, but I lived through it (my
first languages were Algol-60 And Fortran=IV, in 1974, soon followed by
Pascal and Algol-68) and I think that blog post is overly biased by one
particular thread of C's ancestry. CPL, BCPL and B were bit players in the
world of languages (I suspect mostly focused on Bell Labs and/or MIT, at
least US east coast). I should probably blog about my own view of this
history, but basically I don't believe that the distinction between
initialization and re-assignment is the big decider here. Python
historically doesn't care, all its assignments work like dict[key] = value
(with a slight exception for the analyses related to local scopes and
closures).


> I think the "we already use colons in too many unrelated places"
> argument also has merit, as we already use the colon as:
>
> 1. the header terminator when introducing a nested suite
> 2. the key:value separator in dictionary displays and comprehensions
> 3. the name:annotation separator in function parameter declarations
> 4. the name:annotation separator in variable declarations and
> assignment statements
> 5. the parameter:result separator in lambda expressions
> 6. the start:stop:step separator in slice syntax
>

But := is not a colon -- it's a new symbol spelled as two characters. The
lexer returns it as a single symbol, like it does != and ==. And we're
lucky in the sense that no expression or statement can start with =, so
there is no context where : = and := would both be legal.


> "as" is at least more consistently associated with name binding, and
> has fewer existing uses in the first place, but has the notable
> downside of being thoroughly misleading in with statement header
> lines, as well as being *so* syntactically unobtrusive that it's easy
> to miss entirely (especially in expressions that use other keywords).
>

Right -- 'as' signals that there's something funky happening to its left
argument before the assignment is made.


> The symbolic "right arrow" operator would be a more direct alternative
> to the "as" variant that was more visually distinct:
>
>     # Handle a matched regex
>     if (pattern.search(data) -> match) is not None:
>         ...
>
>     # More flexible alternative to the 2-arg form of iter() invocation
>     while (read_next_item() -> item) is not None:
>         ...
>
>     # Share a subexpression between a comprehension filter clause and its
> output
>     filtered_data = [y for x in data if (f(x) -> y) is not None]
>
>     # Visually and syntactically unambigous in with statement headers
>     with create_cm() -> cm as enter_result:
>         ...
>
> (Pronunciation-wise, if we went with that option, I'd probably
> pronounce "->" as "as" most of the time, but there are some cases like
> the "while" example above where I'd pronounce it as "into")
>
> The connection with function declarations would be a little tenuous,
> but could be rationalised as:
>
> Given the function declation:
>
>     def f(...) -> Annotation:
>         ...
>
> Then in the named subexpression:
>
>     (f(...) -> name)
>
> the inferred type of "name" is "Annotation"
>

I am not excited about (expr -> var) at all, because the existing use of ->
in annotations is so entirely different.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180413/c7bddfa2/attachment-0001.html>