JS’ governance model is worth inspecting
JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers. First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run. You can publish your language modification on the JS package manager, npm. When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by 🚀)that is a member of TC-39. The guidelines say that the proposal’s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I’m hazy on what the criterion for each of the three stages is. The fourth stage is approved. I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public. The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language. I’m fairly hazy on the details, this is just the summary off the top of my head. — I’m not saying this should be Python’s governance model, just to keep JS’ in mind.
This feels a bit like apples and oranges. Babel's primary purpose is transpiling to run on older browsers, which isn't that much of an issue with Python. It's also complicated a bit by the large number of implementations that *must* be developed in sync, again due to running in user's browsers. On Fri, Sep 21, 2018, 6:25 AM James Lu <jamtlu@gmail.com> wrote:
JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers.
First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run.
You can publish your language modification on the JS package manager, npm.
When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by 🚀)that is a member of TC-39. The guidelines say that the proposal’s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I’m hazy on what the criterion for each of the three stages is. The fourth stage is approved.
I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public.
The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language.
I’m fairly hazy on the details, this is just the summary off the top of my head.
— I’m not saying this should be Python’s governance model, just to keep JS’ in mind.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/
> Babel's primary purpose is transpiling to run on older browsers, which isn't that much of an issue with Python. It's also complicated a bit by the large number of implementations that *must* be developed in sync, again due to running in user's browsers.
It’s true that one of Babel’s purposes is to transpile to older browsers. However, if you look at the React Native project template (a fairly typical JavaScript project template), the Babel transpiler preset looks like this:
- Remove Flow and transpile JSX: these are language extensions for type hinting and inline XML, not intended to be merged with mainline JavaScript.
- Transpile Standardized JavaScript to older JavaScript
- Stage-3 Proposal: adds dedicated syntax for setting static and instance variables outside of the constructor but within the class.
- Stage-1 Proposal: syntax to support trailing comma in functions
function foo(
a,
b,
c,
) { }
Inspired from Python’s syntax:
def foo(a,
b,
c,
):
...
As you can see, two non-standard features under consideration for inclusion in the standard are included in the preset. This inclusion of non-standard features is typical for JS starter projects. One of the requirements for advancing stages is seeing practical use in the industry.
Since almost everyone uses Babel anyways, this four stage process acts as a way to gain consensus on the base set of JS features.
Almost all of the newest standard JS took this route of unofficial use before official inclusion.
On 2018-09-20 18:56, James Lu wrote:
JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers. <snip> — I’m not saying this should be Python’s governance model, just to keep JS’ in mind.
To my mind, there is one very big reason we should be cautious about adopting JS language-design policies, namely, that they have led to a very, very poorly designed language. No doubt a good deal of that is baggage from early stages in which JS had a poor to nonexistent language design governance model. Nonetheless, the failure of JS to fix its numerous fundamental flaws, and especially the rapid feature churn in recent years, suggests to me that their model should be viewed with skepticism. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
On Thursday, September 20, 2018, James Lu <jamtlu@gmail.com> wrote:
JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers.
https://github.com/tc39/ Python has devs with committer privileges: https://devguide.python.org/experts/ There are maintainers for many modules: https://devguide.python.org/experts/
First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run.
You can publish your language modification on the JS package manager, npm.
Babel plugins are packaged for and installable with npm: https://babeljs.io/docs/en/plugins New ES features can run on older JS interpreter features with transpilation by Babel.
When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by 🚀)that is a member of TC-39. The guidelines say that the proposal’s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I’m hazy on what the criterion for each of the three stages is. The fourth stage is approved.
Is there a link to a document describing the PEP process (with and without BDFL)? That would be a helpful link to add to the table here: https://devguide.python.org/#contributing e.g. "How to write a PEP" as an ISSUE_TEMPLATE/ might be helpful: - [ ] Read the meta-PEPs - [ ] and find the appropriate BDFL-delegate - [ ] copy the PEP 12 RST template - [ ] add the headings specified in PEP 1 - [ ] Read PEP 1 "Meta-PEPs (PEPs about PEPs or Processes)" https://www.python.org/dev/peps/#meta-peps-peps-about-peps-or-processes PEP 12 -- Sample reStructuredText PEP Template https://www.python.org/dev/peps/pep-0012/ PEP 1 -- PEP Purpose and Guidelines https://www.python.org/dev/peps/pep-0001/ PEPs https://github.com/python/peps
I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public.
PEP 1 describes the PEP mailing list and editors.
The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language.
python-dev@, python-ideas@,
I’m fairly hazy on the details, this is just the summary off the top of my head.
— I’m not saying this should be Python’s governance model, just to keep JS’ in mind.
Which features of the TC39 committee's ECMAscript (ES) language governance model would be helpful to incorporate into the Python language governance model?
Wes Turner writes:
Is there a link to a document describing the PEP process (with and without BDFL)?
PEP 1, and https://devguide.python.org/langchanges/# But most changes don't need a PEP. We're only discussing this now because Anders's proposal would need a PEP. In general, though, PEPs are rare. There are many hundreds of pull requests accepted every year, but there only about 500 PEPs (including rejected, withdrawn, and deferred PEPs) over the entire history of Python. Of those, quite a few are Process and Informational PEPs. The Language Changes section is #20, and doesn't get a quick link from the table of links in the "Contributing" section of the home page of the DevGuide. That's as it should be, IMO, so I'm not going to write up a PR to add such a link. YMMV, go right ahead.
participants (5)
-
Brendan Barnwell -
James Lu -
Ryan Gonzalez -
Stephen J. Turnbull -
Wes Turner