Hello, On Mon, 30 Nov 2020 08:48:21 +0000 Paul Moore <p.f.mo...@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. 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. Well, Python is special ;-). More seriously, JavaScript have had the same scoping discipline as Python - variables are function-local, though their introduction requires "var" keyword. But recently, that changed. Well, how recently - a few years ago, now unalienable part of JavaScript, with Python falling behind its biggest competitor. So what they did: So, any language is in dire need of immutable variables (some have such by default, some only such). JavaScript needed them too (dynamic languages actually need them more than static). So, they introduced it. And they introduced it. But per the modern best practices, they introduced it block-scoped. 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. Now, the "const" is the great hit in JavaScript (heck, it was in the *dire* need). What about "let"? Well, it's there, so that the *current* JavaScript designers aren't laughed at for designing it in 2 weeks while on holiday drinking things. It has its usages too, in great demand for egghead phd's, laid off haskell developers who couldn't find better job than to code javascript, all that crowd, you know. Also, scientific studies show that much less people leave JavaScript for Haskell now in the first place. So, if anything, we're re-tracing JavaScript steps. We're in dire need of const'ness in the language. We'll introduce it as annotation first, but likely it will be so useful, that we'll want to make it a keyword. Then a question of scope for variables declared with it will raise. We should not make mistakes then. The stage should be setting already now. [] > > 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. -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/2PDHVNSQHYKT76FUPBSB2JBYJLWSHGQS/ Code of Conduct: http://python.org/psf/codeofconduct/
