> 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
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,
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:
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,
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
> 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
>
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
> 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
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.
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
10 matches
Mail list logo
