On Mon, 30 Nov 2020 at 08:29, Paul Sokolovsky <pmis...@gmail.com> wrote: > > Hello, > > On Mon, 30 Nov 2020 08:11:07 +0000 > Paul Moore <p.f.mo...@gmail.com> wrote: > > > On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky <pmis...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3ULDSE3W7T3S3ZGSS2WTKJ6HJQFZ4CMG/ Code of Conduct: http://python.org/psf/codeofconduct/
