On Thu, Jul 23, 2020 at 07:22:51AM +1000, Chris Angelico wrote:
> Please, everyone, can we NOT keep coming up with ideas that are
> basically "let's invent a new spelling for exactly the same thing,
> with no benefits,
Surely having a less confusing and misleading spelling is a benefit.
We like to use Python because its syntax is so readable and obvious.
"for...else" is a wart on the language, it is a lovely feature marred by
a confusing keyword. The long term benefit is to reduce that confusion.
We have heard from people in this thread that they reject for...else in
code reviews because it is too confusing.
The question to me is not "Why make this change for no benefit?" but "Is
the benefit sufficient to go through the pain of change?".
Guido seems to be open to the use of *soft keywords* now that CPython
has moved to a PEG parser. Perhaps we could introduce a soft keyword as
an alternative spelling for "else":
for x in sequence:
...
then: # allow the bike-shedding to begin :-(
...
Being a soft keyword, outside of that context it will remain legal, so
no-one needs to rename their "then" methods or variables. Code using
"for...else" remains legal, although linters might warn against it.
We need not actually depreciate the use of "else", not unless we plan to
reintroduce it with a different meaning. But that's a separate
discussion. So here's a concrete proposal:
(1) `for...else` and `while...else` stay, for backwards compatibility.
(2) Add a soft keyword "then" (bikeshed away...) to use in for and
while loops, as an alternative preferred spelling to "else".
(3) Update PEP 8 to make it clear that new code should use `for...then`
and `while...then` rather than "else". (Old code need not change just
for the sake of changing it.)
(4) Linters and style-checkers can prefer `then`, but the interpreter
itself will remain neutral and accept both.
To avoid all doubt:
(5) There is no plan to depreciate the hard keyword `else`, not even a
PendingDepreciation warning.
(6) Any suggestion that we repurpose `for...else` to mean "run this if
the loop is empty" will have to justify itself. It is not part of this
proposal.
It seems to me that this is a pretty minor change, with little downside,
that could have a big effect on the readability and usefulness of what's
currently spelled as `for...else` and underused because people find it
confusing. Compared to the benefits, the downsides are small:
- Someone has to do the work. That's a one-off cost.
- Double the tests: we have to verify `for...else` and `for...then` both
work. This is a pretty small cost.
- Two ways to do it. Despite the Zen, there are two ways to do many
things in Python. But this is a pure alias: for...then and for...else
are literally compiled to the same code. The Zen should be understood as
*food for thought* not unbreakable rules of nature. If we accept this
proposal, we could interpret it as follows:
* the One Way to do it is `for...then`;
* but for backwards compatibility there's also an alternative
spelling that we prefer not to talk about, see the docs if
you care.
There are no runtime costs. The compiler should generate the exact same
bytecode for the two spellings. There's no breaking backwards
compatibility, as `then:` followed by a block is not currently legal. If
`then` is a soft keyword, existing uses of "then" won't be affected.
> and demanding new keywords, so we can break people's
> code for no reason"? You can always just write your own transpiler to
> let yourself spell it your preferred way.
How do I do that?
That's not a rhetorical question. I keep wanting to study projects like
LikePython for hints, because I am sick of *Old Man Python* telling
me what I can and can't write, but somehow never find the time.
https://jon.how/likepython/
If we had some sort of easy to use standard library support for
transpiling code, then your advice could actually be practical and not
just dismissive. "Pft, if you don't like it, write your own language" is
not exactly practical for most people. Even if a transpiler is a tad
simpler than writing an entire interpreter or compiler, it's still a new
language.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CAABTU7PYU3CPUWCAFDZNUEXY24VPAGQ/
Code of Conduct: http://python.org/psf/codeofconduct/
