Re: [Python-ideas] JS? governance model is worth inspecting
> Which features of the TC39 committee's ECMAscript (ES) language governance > model would be helpful to incorporate into the Python language governance > model? Having “beta” or “alpha” editions of features, special versions of the interpreter people can test out to see if they prefer the version with the new feature. To prevent splintering, the main releases would only support the main feature set. In a worst case scenario, people can compile incompatible code to .pyc before running it. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
On Thursday, September 20, 2018, James Lu 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? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
Michel Desmoulin writes: > [W]e should not disregard the design policies because of these > particular issues. Please stop. As long as core developers don't get involved, it's just noise. If you must continue this thread, PEP it. No major change in the procedures described in the DevGuide, PEP 1, and so on will take place without a PEP. If you're serious, you'll have to put in that much effort to get a hearing. If you're not, you're wasting lines in my mail client's summary screen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
Le 22/09/2018 à 20:27, James Lu a écrit : > > 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. > I disagree. The language is often very flexible and effective in its domains. I don’t know what you mean by “rapid feature churn”, churn usually means existing features are superseded by newer ones- this isn’t the case. > > JS is much more nuanced than it appears on the surface. It’s understandable that those with only a glossing of JS look down on it, because JS really was a primitive language a few years ago. > > You can learn about JS in depth with the poorly-named “You don’t know JS” free online book. > I worked with JS for the last 10 years, and I agree that "we should be cautious about adopting JS language-design policies", particularly about the fact they completly ignored readability in their concerns. But still, using the old JS baggages to justify we reject what they are doing currently is not a good argument: - they can't break the whole Web so deprecation is very hard. Python 2 => 3 should make us understand that. Yes it sucks you can still declare a variable global by default. It also sucked we had to rewrite most good python modules during the last decade. - the new JS features have been so far a good fit for the language and overall made it better. - fast pace evolution is only for the JS ecosystem (and I agree it's terrible). But the spec and implementations have been very reasonable in their progress. Now it's hard to know if it's because of the design policy or in spite of it. But while I still dislike JS, it IS a vastly better language that it used to be and we should not disregard the design policies because of these particular issues. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
> 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. I disagree. The language is often very flexible and effective in its domains. I don’t know what you mean by “rapid feature churn”, churn usually means existing features are superseded by newer ones- this isn’t the case. JS is much more nuanced than it appears on the surface. It’s understandable that those with only a glossing of JS look down on it, because JS really was a primitive language a few years ago. You can learn about JS in depth with the poorly-named “You don’t know JS” free online book. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
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. — 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
> 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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JS’ governance model is worth inspecting
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 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/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
