Hello. That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme. What do you think about actually naming PyPy release 2.5 after language version it supports? We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?). Cheers, fijal
On Apr 16, 2009, at 4:27 PM, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
This will be a lot simpler for end users of the pypy python interpreter, but it blur the line even more between pypy the toolkit and pypy python interpreter. maybe naming and versioning them differently might help (pypy-toolkit 1.1 and pypy-2.5), but I really don't know. But the name pypy-2.5 and later pypy-2.5-jit put directly in the name the most important features of pypy (the project). []'s -- Leonardo Santagada santagada at gmail.com
Hi Maciej, On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme. Also, we might be starting sometime to release a pypy that can generate interpreters for two different CPython versions - how would you name this? cheers, holger
Cheers, fijal _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu
On Thu, Apr 16, 2009 at 1:46 PM, holger krekel <holger@merlinux.eu> wrote:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme. Also, we might be starting sometime to release a pypy that can generate interpreters for two different CPython versions - how would you name this?
cheers, holger
That's exactly the reason why I would like to separate language number from pypy advances in other areas, so we can separate two issues. It seems unlikely that we can come up with two different python versions, but even if we do we can invent new naming scheme. I just think pure numbering, like 1.1 is completely meaningless (but it actually supports language version 2.5).
On Thu, Apr 16, 2009 at 13:50 -0600, Maciej Fijalkowski wrote:
On Thu, Apr 16, 2009 at 1:46 PM, holger krekel <holger@merlinux.eu> wrote:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme. Also, we might be starting sometime to release a pypy that can generate interpreters for two different CPython versions - how would you name this?
cheers, holger
That's exactly the reason why I would like to separate language number from pypy advances in other areas, so we can separate two issues.
It seems unlikely that we can come up with two different python versions, but even if we do we can invent new naming scheme.
I just think pure numbering, like 1.1 is completely meaningless (but it actually supports language version 2.5).
version numbers are just meant to indicate and communicate progress. Maybe it's true that the upcoming pypy release is mainly about 2.5 compat, although there also is better cross-platform compilation support, optimizations, stackless, sandboxing and other bits of interest that all not relate much to the "2.5" mem. For the next releases, as you say, it's likely first going to be about the JIT, and i think that's when we should go pypy "2.0", because it's a big step forward. Inventing "2.5-jit-5.0" or something like would be relatively obscure IMO. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme. Also, we might be starting sometime to release a pypy that can generate interpreters for two different CPython versions - how would you name this?
Maybe keep the numbering, but give releases some fancy names, like ubuntu, but regarding on what features are central within this release. Let's say: pypy-1.1-two-point-fiver pypy-2.0-jitted Até já! Jakub Gustak
2009/4/16 holger krekel <holger@merlinux.eu>:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme.
But to users of Python on PyPy, the corresponding CPython version is more important than say a new GC. Perhaps there should be two versions? -- Regards, Benjamin
On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
2009/4/16 holger krekel <holger@merlinux.eu>:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme.
But to users of Python on PyPy, the corresponding CPython version is more important than say a new GC. Perhaps there should be two versions?
We are still doing a source-release, though. Maybe a name like "pypy-c-2.5-1.1" for the generated and compiled Python interpreter would make sense? That would also likely be the one that people see once it e.g. gets packaged in debian. best, holger
-- Regards, Benjamin _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu
On Thursday 16 April 2009 22:36:34 holger krekel wrote:
On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
2009/4/16 holger krekel <holger@merlinux.eu>:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme.
But to users of Python on PyPy, the corresponding CPython version is more important than say a new GC. Perhaps there should be two versions?
We are still doing a source-release, though. Maybe a name like "pypy-c-2.5-1.1" for the generated and compiled Python interpreter would make sense? That would also likely be the one that people see once it e.g. gets packaged in debian.
best, holger
I don't think features of a release should go into version number, they can go to release code name, but that's more of a marketing plan than a matter of versioning in my opinion. I'd go with something along pypy-1.1-cpython2.5 pypy2.5-1.1 which I think is very informative about both the syntax and CPython features compatibility and also PyPy version. Of course, release notes should generously explain main features and also CPython compatibility. Regards, Gasper Zejn
On Thu, Apr 16, 2009 at 23:31 +0200, Gasper Zejn wrote:
On Thursday 16 April 2009 22:36:34 holger krekel wrote:
On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
2009/4/16 holger krekel <holger@merlinux.eu>:
Hi Maciej,
On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
Hello.
That might sound a bit like bike sheding, but I would like to talk a bit about naming scheme.
What do you think about actually naming PyPy release 2.5 after language version it supports?
We can invent suffixes like pypy-2.5-something in order to release still 2.5, but which supports some more things (like JIT?).
i think that PyPy's advances are not too much related to language compat issues but rather to better GCs, stackless, JITting, optimisations, etc. So i don't see the language compat as the central theme.
But to users of Python on PyPy, the corresponding CPython version is more important than say a new GC. Perhaps there should be two versions?
We are still doing a source-release, though. Maybe a name like "pypy-c-2.5-1.1" for the generated and compiled Python interpreter would make sense? That would also likely be the one that people see once it e.g. gets packaged in debian.
I don't think features of a release should go into version number, they can go to release code name, but that's more of a marketing plan than a matter of versioning in my opinion. I'd go with something along
pypy-1.1-cpython2.5 pypy2.5-1.1
hum, maybe. Let's see what the people that are sprinting think about all this. I can live with anything but keep with my stated preference. I am +1 an an all-crazy new release number and name for the JIT release - i like maciej's suggestion of "kickass koala" :)
which I think is very informative about both the syntax and CPython features compatibility and also PyPy version. Of course, release notes should generously explain main features and also CPython compatibility.
sure. cheers, holger
Regards, Gasper Zejn
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu
participants (6)
-
Benjamin Peterson -
Gasper Zejn -
holger krekel -
Jakub Gustak -
Leonardo Santagada -
Maciej Fijalkowski