On Mon, 30 Nov 2020 at 08:29, Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
On Mon, 30 Nov 2020 08:11:07 +0000 Paul Moore p.f.moore@gmail.com wrote:
On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky pmiscml@gmail.com wrote:
On the other hand, block-scoped variables are implemented in:
- C
- C++
- Java
- Rust
- Lua
- JavaScript (not by default, as opt-in)
- Scheme
- Common Lisp (as opt-in)
- ML
- Ocaml
- Haskell
- 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.
You seem to be treating "block-scoped" variables as different from function-local variables. I know of *no* other language that makes such a distinction, much less requiring different syntax for them.
The aim of the block scoping proposal is to make Python *not worse* than these other languages, instead of adding funny workarounds again.
One of the ways in which Python is *better* than these languages is in not requiring variables to be declared. Let's not make the proposed Python *worse* than the current version of Python, by making variable declarations common.
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.
Paul