Paul Sokolovsky writes:

 > Well, I'd call that "cowboy attitude in programming language
 > design" ;-).

That was uncalled for, especially since you're selling an idea without
an implementation yourself.

 > We'd certainly make it blend well with the rest of Python.

But how long will that take?  People have wanted f-strings since
forever (1.5 is as far back as I go, PEP 215 was July 2000).  We got
them in 3.6 (December 2016), the delay basically due to "blending"
issues.  And that was for a quite self-contained feature.

This one strikes me as likely to be messy.  How does we get
consistency if we don't change for?  How do block locals interact with
global, nonlocal, and locals()?  Do we need a block_locals()?

Currently all suites in a multiarmed statement (if, for, while, try)
are in the same scope.  I suspect that when I'm reading other people's
code I'd almost certainly read a let/const var = init_val as suite-
local in such contexts, while in my own code I'd probably want to use
it as statement-local a lot.  Of course that latter is easy to handle
by creating a new suite with something like "if 1" (as you suggest
elsewhere), but creating unconditional 1-statement suites just to
declare block-locals seems excessively inelegant. :-/  But requiring a
"block" statement to create a slope in common cases like a one-armed
if or for is equally inelegant (and surely more common).

 > The problem is that intuitively (just like with "for"),
 > "case a, b if a != b:" opens a new namespace for "a" and "b".

I don't find a new namespace in either of those contexts intuitive at
all.  Nor do I find it unintuitive at all.  A language will define
rules for scoping, I'll learn them.
Python-Dev mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Reply via email to