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.
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.