[karbarcca]

One advantage I've noticed at least (having been a contributor to the Julia language itself), is that it at least makes contributing to the language very approachable. Granted you see lower quality proposals from time to time, but in general, I even question whether I myself would have gotten involved or been brave enough to propose language features if I would have had to do such a rigorous, formal PEP writeup. In some respects, you're restricting the pool of people who actually contribute ideas to the language.

I also have appreciated the "meritocratic" approach of Julia language features; if someone can show that an idea/approach/algorithm is fundamentally faster, more flexible, etc. it's generally been accepted, regardless if the proposer is a first-time contributor or not. That also makes contributing feel approachable and very fair, as opposed to just trying to please a single core developer or playing some politics game.

[oefrha]

> if someone can show that an idea/approach/algorithm is fundamentally faster, more flexible, etc. it's generally been accepted, regardless if the proposer is a first-time contributor or not.

If you can submit a measurably faster csv implementation to cpython (without breaking existing code of course) I can guarantee it will be welcome whether you’re a first time contributor or not. Not sure about your definition of “more flexible”, if that entails breaking existing code then it may rightfully meet resistance.

Not sure why you’re implying other languages’ proposal processes are about pleasing a single core developer or playing some politics game. Sounds like either you have a lot more experience than I do and hence have been exposed to politics games or anything else non-meritocratic (that I haven’t sensed in CPython development, at least), or you just don’t have as much experience contributing to other languages.

(I'm a bit cranky today. Sorry if I sound aggressive.)

[karbarcca]

No worries, it doesn't come off that aggressive ;)

Yes, I've definitely been involved in other projects where a single core developer can do a little too much "imposing" of their will. i.e. if they happen to have a personal preference one way or another on things, they not accept or even entertain certain changes.

I wouldn't expect most large, mature projects to be this way (otherwise they probably wouldn't have grown as large or attracted enough of a community!), but it's certainly a problem with some projects.

[oefrha]

> it's certainly a problem with some projects.

Projects, of course. Ages ago I quit a notable project partly because of maintainer team politics, so I'm no stranger. But I thought we were specifically talking about language improvement processes of non-niche programming languages (a specific one, even).

[woadwarrior01]

> If you can submit a measurably faster csv implementation to cpython (without breaking existing code of course) I can guarantee it will be welcome whether you’re a first time contributor or not.

I wouldn't be so sure. Search for `site:bugs.python.org "maintenance overhead"` on your favourite search engine.

[oefrha]

8 results total, with exactly one entry that’s remotely relevant (i.e. performance related, patch provided) — bpo-21955. You could have just linked that. And this happens to be a patch from a core dev. And it’s not comparable to submitting a performant implementation of a PSL module like csv. You have chosen a pretty convincing example, I don’t know what I’m supposed to be convinced of though.

https://bugs.python.org/issue21955