On Sat, Jul 25, 2020 at 11:13 AM Steven D'Aprano firstname.lastname@example.org wrote:
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.
Minor, given that the existing spelling still has to be supported. Now you have two ways to do it, for the foreseeable future, and only style guides will differentiate. And a lot of style guides will say "prefer else because it's compatible with more Python versions". How long will it be before you can actually take advantage of it?
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.
I don't dispute that, but that's very long term benefit, with a lot of short and medium term costs. The concept is a bit unusual (I don't know many other languages that support this with *any* spelling), so it still has to be explained, and a lot of people will still be confused no matter how you spell it. How much benefit do you actually gain?
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.
That's a notable reduction in cost (and an improvement in flexibility for the bikeshedding - although that will, of course, mean that the bikeshedding takes ten times longer!), but the cost of creating a second way to do things isn't just the creation of the keyword.
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.
Linters and style checkers will have to choose whether to recommend the "better" spelling (unquantifiable benefit) or the one that runs on more versions of Python (concrete, meaningful benefit).
(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.
I hope nobody EVER proposes that. Having code that means different things on different Python versions would be an absolute pest to work with. But if all the prior objections are overcome and "for... then" gains currency, there'd be some reasonable grounds for proposing a completely different keyword to have the "if loop is empty" semantics.
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.
And all your documentation, examples, etc, have to care.
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.
It depends how smart you want it to be. If you literally just search and replace "then:" into "else:" without caring about context, it'd be trivially easy. Obviously that's pretty risky, but adding a check for string literals would probably cover most normal code. Actually doing the job properly...
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.
... would be best done with stdlib support, yes. I think import hooks can do everything that's needed, but I've never actually done it. Normally I'd just use a simple source-to-source transformation before execution, and usually I do things that aren't ever going to show up (string literals aside), so I don't need it to be very smart.