Hello,
On Mon, 30 Nov 2020 14:45:26 +0900
"Stephen J. Turnbull" wrote:
> Paul Sokolovsky writes:
>
> > Also to clarify, [cowboy attitude] referred to difference in
> > approaches in response to particular issue(s) raised. One thing is
> > to say "it's hard to implement it better with the limited VM
> > infrastructure and resources we have" (that of course leads to
> > further questions/discussion), it's different thing to say to the
> > same matter "issue exists, but it's not really an issue".
>
> Of course those are *different*. Where I differ with you is on
> whether "I understand the case are describing and that you want to do
> something about it, but we don't consider that a problem" is "cowboy
> attitude".
Right, all people are different. That's great!
> My experience is that the development community will care when it
> perceives that a change serves the greater community (eg, f-strings
> and data classes, which are universally loved), or when a sufficiently
> large coalition of committers can be convinced. That's what you need
> to do, and accusing the core developers of cowboy attitude is not a
> good start IMO.
Sorry, but there may be a suggestion of tactics of sneaking somebody's
"pet feature" past the attention of core developers by employing
sycophant techniques. That's certainly not me. Let the criticism begin.
Both of "doing it" and "not doing it".
> > Maybe one of these years would be good time, after so many
> > usability changes, to also tighten up theoretical side with
> > block-level scoping.
>
> Maybe it is. I certainly hope not, because I like Python as it is,
But then you've already lost, because today's CPython (3.9) is not like
that of a year ago, and that one is not like that of 2 years ago, and
it all has been changing at alarming pace. So, calling for "stop the
world" right now seems to be a bit ungrounded, if anything, newer
changes proposed take inspiration in the changes already done.
> where I rarely have to deal with declarations separate from
> instantiation, and code is highly dynamic without a compiler
> complaining, perhaps even going on strike, any time I want to do
> something whose semantics I know to be sound even though the compiler
> can't prove that from the syntax.
Good news is that it all stays. But if you want all that, perhaps you
appreciate that some other people may want different things too. Like,
more speed (JIT), better scalability to complex codebases, tighter
formal side (syntax/semantics), etc.
> Yes, I know you claim that your proposed syntax won't be in my face,
> and quite possibly you're right with respect to the obstreperous
> compiler. But I also know that you make claims that are provably
> false, such as not making me use the syntax. True, short of XKCD 538
> you can't make me write it, but if it exists somebody will make me
> read it.
Ok, it will be it will be a fun cute read, calling for existing
memories (or for youngest of us actually teaching them useful things,
which apply outside Python too).
> > The simplest answer is that they don't (interact with existing
> > overdynamic features).
>
> You say "overdynamic", I say "works for me".
... And some say "slow".
> > They are new enough, opt-in concepts, and so can start from blank
> > page.
>
> You're BS-ing here -- you back off in the next sentence (quoted
> below). And from the community's point of view, no syntax is truly
> opt-in because we often work with Other People's Code. We need to
> read it, and often in open source we are modifying code whose style is
> "owned" by someone else -- if I were to work on code you maintain, I'm
> pretty sure you wouldn't hesitate to query "shouldn't this variable be
> block local" or even refuse to accept code that didn't have the block
> locals you think it should have.
But if you anticipate that there may be people who will use block-local
vars in Python "when they should have been", don't you think that
"saving" them from that by simply not letting them hold of block-scoped
vars is a bit ... umm, backward way to tackle the issue?
Beyond that, "it's going to be a fun cute read". If anything, we can
judge by experience of others. If you see a "let" in JavaScript code,
you can google up "javascript let" and in a minute you will be back to
your pleasurable code-reading. And "let" ("still", "so far") doesn't
appear that often in JavaScript code. Unlike it's counterpart "const"
which has the same block scope, but very obvious semantics, so many
people won't even google it on first sight (only later).
Do you think it would be worse than that with us? I don't.
> A lot of effort and persuasion (and more or less silent acceptance of
> the slings and arrows from outraged dynamicists) went into the
> introduction of type hints. I think this will require more of the
> same (although maybe not: type hints are intentionally pervasive for
> those who use them, these declarations will presumably be occasional).
