[Python-ideas] Modern language design survey for "assign and compare" statements
steve at pearwood.info
Sat May 19 03:49:18 EDT 2018
On Sat, May 19, 2018 at 02:11:38PM +1200, Greg Ewing wrote:
> Chris Angelico wrote:
> >The 'as' syntax has been hammered out in great detail and is no longer
> >recommended due to its negative interactions with existing constructs.
> Allowing it in arbitrary expressions has been ruled out on
> the grounds that the difference between "with x as y:" and
> "with (x as y):" would be too subtle.
> But that argument doesn't apply if "as" becomes part of the
> syntax of "if" and "while". Do we think that's a bad idea
> as well?
Yes. What is so special about "if" and "while" that they and they alone
can make use of assignment expressions?
The `and` and `or` short-cut operators are only useful in `if` and
`while` statements, so we ought to prohibit them outside of `if` and
`while` statements. Do you agree?
Either assignment expressions are useful, and they should be allowed
anywhere an expression is allowed, or they aren't, and they shouldn't be
allowed at all.
Breaking the rules for a special case is rarely the right decision.
> From the survey of other modern languages that was just
> posted, it seems we'd be in good company if adopted something
> like that.
Compared to the Zen of Python, Go seems to break all the rules. Or at
least most of them -- the beauty of the Zen is that it is open to
Go doesn't have exceptions. It requires the use of the tedious old
flag, result = function()
do what you want
# Now how the hell do I handle this?
as a fundamental design principle, apparently because ugly and tedious
boilerplate is a good thing, giving us all the verbosity of EAFP at its
worst without any of the benefits.
Similarly, its 2018 and the designers of Go turned their back on about
4/5th of the world, insisting that strings are ASCII and Unicode is an
I'm sure Rob Pike has his reasons for prohibiting exceptions, and
network engineers probably think text is just another data format. Go
might be an awesome language for what it is designed to do, but Forth is
an awesome language for what it does best too, and we don't copy Forth's
way of doing things.
Before we copy Go, whether we copy a feature or a lack of feature, we
ought to carefully consider how well that fits Python.
(Sorry to just pick on Go, but it is the one I'm most familiar with.)
More information about the Python-ideas