On Mon, 30 Nov 2020 08:48:21 +0000 Paul Moore email@example.com wrote:
On the other hand, block-scoped variables are implemented in:
- Common Lisp (as opt-in)
- very long list of other languages...
How many of these languages don't require any sort of variable declaration for all but a tiny minority of variables?
I don't see to what your question applies. The proposal to introduce block-scope variables in Python relies on a special keyword to introduce them. So, any language with support for block-scoped vars would require "declaration", Python including. (But Python and some other languages keep non-block-scoped vars without any decls.)
To cover some of the languages I know,
C, C++ and Java require *every* variable to be declared. Rust requires every variable to be declared, at least to the point of using "let". You can't introduce a variable just by using it. In Lua, variables introduced by assignment are global, even function-local variables need "local".
Conversely, in Python, x=12 introduces a function-local name x, if used in a function. Without any sort of "declaration", or keyword.
That feature stays.
You seem to be treating "block-scoped" variables as different from function-local variables.
Literally, block-scoped vars are block-scoped, and require special syntax to introduce them. Do *you* treat them much differently beyond that?
I know of *no* other language that makes such a distinction, much less requiring different syntax for them.
So what they did:
So, they introduced block-scoped immutable variables. Ant to not leave accidental gap (https://en.wikipedia.org/wiki/Accidental_gap) in the language, they also introduced mutable block-scoped, with the "let" keyword.
They won't be common, if people don't find common need for them (they shouldn't). If they do... oh, people!
So you're saying this proposal is to add new syntax and semantics to Python for an uncommon situation? You can't have it both ways. Is this proposal useful to a lot of people (and hence worth new syntax/semantics) or is it uncommon (and as a result, likely not worth the disruption).
I'm ambivalent, with a bias towards saying that we don't need this, to the proposal. But I'm finding your arguments confusing and inconsistent. It feels like it's almost impossible to discuss the specifics of the proposal, as you're not taking a consistent position to debate against.
So, the quest is for the fundamental, "atomic", orthogonal yet well-composable features which can be (re)used to address various (ideally, as many as possible) Python language design challenges and issues. This necessary makes the discourse topic wide, and people constantly bring up fringe issues like "but C has mandatory variable declarations!", "what about debuggers?", "what about locals()?".
All that makes following the mailing list discussion hard, yes. I guess, for now we reached its limits. People interested in the topic should find enough food for reading and thought.
But those fundamental, orthogonal language features under scrutiny are clear and simple:
1. Const'ness aka variable immutability. 2. Block-level scope.