7 ms·

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main proj

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.

JoeAltmaier 6y ago
An issue. But isn't that forking fundamental to the principle of Open Source? The market will choose what it wants, like some Genetic Algorithm where the fittest thrives and the rest go extinct. Else how does a project evolve at all?
WesolyKubeczek 6y ago
Disagree. Currently, many people have "Python" projects which only CPython can run, for some reason or other. Having a lot of competing interpreters/compilers helps define what the core of the language actually is, and which of your assumptions are hinged on that single implementation.
rudi-c 6y ago
That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project. Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project. So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream. Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.
imtringued 6y ago
The solution to that is not to stick your head into sand, it's to merge the desired changes.
yegle 6y ago
Sure, but who to blame? There's no such thing as "Python Language Specification", and everyone is trying hard to be CPython-compatible (but ~impossible as your implementation need to be compatible with various C-written module). Should there be a "language spec", competing implementation would make the language stronger not weaker. Examples include gccgo, various Java vm, C++ compilers.
- xapata 6y ago
  I'm pretty sure you can find the Python language specification in the form of documentation at python.org. Some things that CPython does are occasionally misconstrued as specification, but the docs usually call that out.
  - yegle 6y ago
    The closest thing to a "language spec" is https://docs.python.org/3/reference/index.html https://docs.python.org/3/reference/index.html, which still contains a lot of CPython specific/internal implementations (e.g. https://docs.python.org/3/reference/datamodel.html?highlight=cpython https://docs.python.org/3/reference/datamodel.html?highlight...). This, and combined with https://www.hyrumslaw.com/ https://www.hyrumslaw.com/, makes this "Python Language Reference" a "CPython Language Reference".

JoeAltmaier 6y ago

An issue. But isn't that forking fundamental to the principle of Open Source? The market will choose what it wants, like some Genetic Algorithm where the fittest thrives and the rest go extinct. Else how does a project evolve at all?

WesolyKubeczek 6y ago

Disagree. Currently, many people have "Python" projects which only CPython can run, for some reason or other. Having a lot of competing interpreters/compilers helps define what the core of the language actually is, and which of your assumptions are hinged on that single implementation.

rudi-c 6y ago

That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project. Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project. So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream. Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.

imtringued 6y ago

The solution to that is not to stick your head into sand, it's to merge the desired changes.

yegle 6y ago

Sure, but who to blame? There's no such thing as "Python Language Specification", and everyone is trying hard to be CPython-compatible (but ~impossible as your implementation need to be compatible with various C-written module). Should there be a "language spec", competing implementation would make the language stronger not weaker. Examples include gccgo, various Java vm, C++ compilers.

xapata 6y ago
I'm pretty sure you can find the Python language specification in the form of documentation at python.org. Some things that CPython does are occasionally misconstrued as specification, but the docs usually call that out.
- yegle 6y ago
  The closest thing to a "language spec" is https://docs.python.org/3/reference/index.html https://docs.python.org/3/reference/index.html, which still contains a lot of CPython specific/internal implementations (e.g. https://docs.python.org/3/reference/datamodel.html?highlight=cpython https://docs.python.org/3/reference/datamodel.html?highlight...). This, and combined with https://www.hyrumslaw.com/ https://www.hyrumslaw.com/, makes this "Python Language Reference" a "CPython Language Reference".