On Fri, Apr 13, 2018 at 7:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 13 April 2018 at 22:35, Chris Angelico <ros...@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)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/