On 5 Jan 2021, at 11:38, Paul Sokolovsky <pmiscml@gmail.com> wrote:

Hello,

On Tue, 5 Jan 2021 21:03:06 +1100
Chris Angelico <rosuav@gmail.com> wrote:

On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky <pmiscml@gmail.com>
wrote:
And you seem to have 2nd level miss about this miss. I'm not the 1st
asking about braces in Python, hundreds of people embraced braces
(sorry for the pun) in Python for decades (references are in other
messages of this thread). Apparently, they forgot to ask for
"acceptance", and accepted it themselves.

The problem? There's high duplication of effort in that area, and
the same implementation bugs are repeated again and again. So the
question is whether someone who did it, tried to spec out what they
did, what is the test process, etc.

So my question to you is: Why raise all these threads on python-ideas
that have approximately zero chance of being accepted into the core
language?

Simple question, simple answer: majority of stuff posted on
python-ideas has approximately zero chance of being accepted into the
core language.

In this regard, braces aren't worse than average other stuff posted
here. Actually, it might be a bit more interesting, as it clearly moved
people throughout the years.

That’s questionable. The primary reason I’ve seen so far is folks that dislike significant whitespace or mis the braces in they had in other languages (to put it bluntly).

But as Chris has noticed there’s about 0 chance that any proposal for adding braces as an optional feature will be accepted. A lot of other proposals also have little chance of being accepted, but they do inform development of either the language or some library. In some sense reading about problems folks run into with the language are in general more interesting than full formed ideas because most of us aren’t very good language designers (and I count myself in that category).

Why not create a new community of Bracey Python people, and
build a language and an ecosystem around that?

Is it because you think that you wouldn't get enough people?
Because... that would be a good reason not to do it, and a good reason
for the core language to continue to not do it.

There were good reasons to not have string interpolation in the core
language for decades then - KABOOM - there's string interpolation. You
see a pattern yet? No? Oh, let's just keep watching.

I don’t agree, in hindsight there’s a clear path to the introduction of f-strings. There’s also loads of features that have been proposed for a long while and never were added to the language, and never will for one reason or another. Anyways… That some unrelated feature was accepted is not an argument in favour of this feature.

For everyone else who misses the point: the talk is about *alternative*
(second) syntax. Nothing happens to the main indent-based syntax. Only
people who need braces syntax would use it, just as they have been
doing for decades.

They can continue to use a 3th-party project for that. Having an formal alternative syntax at the very least sends out the signal that the language designers think that this is a good idea, and from what I’ve read in the past that’s not going to happen.

Whether a particular implementation (it's a common joke on the Python
lists to mistake a language and a particular implementation) supports
alternative syntax out of the box is irrelevant. It's no more different
to having a separate typechecker or a separate script to run venv in a
subshell (a recent case brought up here on the list).

That folks are mistaken about the distinction between the language and an implementation is to be expected, that happens with formally standardised languages as well (my code works with compiler X and not with compiler Y, therefore compiler Y is broken).