On 13 April 2018 at 22:35, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Apr 13, 2018 at 10:22 PM, Steven D'Aprano <st...@pearwood.info> wrote: >> On Wed, Apr 11, 2018 at 11:50:44PM +1000, Chris Angelico wrote: >> >>> > Previously, there was an alternative _operator form_ `->` proposed by >>> > Steven D'Aprano. This option is no longer considered? I see several >>> > advantages with this variant: >>> > 1. It does not use `:` symbol which is very visually overloaded in Python. >>> > 2. It is clearly distinguishable from the usual assignment statement and >>> > it's `+=` friends >>> > There are others but they are minor. >>> >>> I'm not sure why you posted this in response to the open question, but >>> whatever. The arrow operator is already a token in Python (due to its >>> use in 'def' statements) and should not conflict with anything; >>> however, apart from "it looks different", it doesn't have much to >>> speak for it. >> >> On the contrary, it puts the expression first, where it belongs >> *semi-wink*. > > 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 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 "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). 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" Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
