On Sun, Feb 14, 2021 at 11:54:21AM +0300, Paul Sokolovsky wrote:
> > > b) Python already uses "->" for function return *type*. And there's
> > > idea to generalize it to *function type* in general. E.g. a function
> > > "(a, b) => a + b" can have type "(int, int) -> int".
> >
> > This supports the idea of using "->" as the "return operator". In
> > annotations, it annotates the return *type* and in function bodies it
> > marks the return *value*.
> >
> > (a:int, b:int -> int) -> a*b
> >
> > Why have two different "return operators"? That can only lead to
> > confusion:
>
> Because even calling them "return operators" is "abuse of notation".
You're right, thank you for the correction.
They aren't operators, although people will call them that, just as the
speak of name.attr as "the dot operator".
Let me rephrase it: Why have two different return **symbols** when they
are so closely related?
> And because things "returned" are wildly different. If first case, it's
> *value*, in second - it's *type*.
This is a small and unimportant difference, and with good type inference
the second is redundant. The critical feature here is not what is
returned, but the fact that it marks a return.
The first is a symbol that marks the value returned. The second is an
annotation symbol that marks the type of the value returned.
There is no syntactic or semantic confusion between the two, the
difference is obvious from context to both the human reader and the
interpreter.
Having two different symbols for this would be like having two ever so
slightly different keywords for for loops and comprehensions:
for x in sequence: block
[expression por x in sequence]
For loops are widely different from comprehensions! The first is a block
statement, the second is an expression, these are completely different
things and should have completely different keywords to avoid confusion!
No. This would *cause* confusion when people fail to remember the
difference between for and por (Spanish, for those who wonder), and
there would be a continual stream of people asking "what's the
difference between for and por?"
And so there will be confusion when people fail to remember the
difference between -> and => and have to ask what the difference is. And
people will confuse => with >= as you already did.
Being different just for the sake of being different is a bad idea, but
being different because -> is a better fit to the existing language is
an excellent idea.
We should not choose the more confusing, error-prone solution out of
fear of being different. Python is already different from Javascript in
every regard:
- the basic execution model is different;
- the object model is different;
- the numeric model is different;
-the truthy/falsey model is different;
- the syntax is different;
- the list of keywords is different;
- the standard library is different;
- the list of operators is different;
- even basic equality is different;
- the culture of the community is different.
"Javascript spells it this way" might be a compelling argument if the
choice between the two symbols was neutral, but it isn't:
* the double line arrow => is confusable with greater-than-or-equal;
* the single line arrow -> is already used in Python for a related,
but unambiguously distinct, meaning.
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BB6USWWZABHIXNKVMVUO4N3SDQ4PUYSP/
Code of Conduct: http://python.org/psf/codeofconduct/
