> On 5 Jan 2021, at 11:38, Paul Sokolovsky <[email protected]> wrote: > > Hello, > > On Tue, 5 Jan 2021 21:03:06 +1100 > Chris Angelico <[email protected] <mailto:[email protected]>> wrote: > >> On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky <[email protected]> >> 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). Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5KJ2VE3G72VLUKSPHHM6J5MAMB657LOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
