Hi all, Any volunteer to handle the PyPy3 release corresponding to PyPy 2.2? A bientôt, Armin.
Hi Armin, What would this involve? I ask not only for my benefit but also for any other newbies that may be lurking here and thinking about getting involved :-) Thanks Rami On Wed, Nov 27, 2013 at 5:25 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi all,
Any volunteer to handle the PyPy3 release corresponding to PyPy 2.2?
A bientôt,
Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Rami Chowdhury "A mind all logic is like a knife all blade - it makes the hand bleed that uses it." -- Rabindranath Tagore +44-7581-430-517 / +1-408-597-7068 / +88-01771-064063
Hi Rami, On Fri, Nov 29, 2013 at 8:20 PM, Rami Chowdhury <rami.chowdhury@gmail.com> wrote:
What would this involve? I ask not only for my benefit but also for any other newbies that may be lurking here and thinking about getting involved :-)
http://doc.pypy.org/en/latest/how-to-release.html A bientôt, Armin.
On Nov 27, 2013, at 9:25 AM, Armin Rigo wrote:
Hi all,
Any volunteer to handle the PyPy3 release corresponding to PyPy 2.2?
I wasn't intending to cut another release until I finished the integer re-optimizations I've been tackling lately, but we could do one anyway. It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though? Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple < (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever. -- Philip Jenvey
On 02/12/13 21:08, Philip Jenvey wrote:
It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?
Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple < (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.
another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles. I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number > (2, 2).
On Dec 2, 2013, at 3:13 PM, Antonio Cuni wrote:
On 02/12/13 21:08, Philip Jenvey wrote:
It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?
Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple < (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.
another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles.
For this particular issue the suffix could be 'pypy3' instead. Though this is not ideal, should 'PyPy3' be reflected in sys.version, sys._mercurial[0], platform.python_implementation(), etc?
I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number > (2, 2).
This would be weird but I don't think it would break any version number checks, being a higher number. -- Philip Jenvey
On 12/03/2013 03:42 AM Philip Jenvey wrote:
On Dec 2, 2013, at 3:13 PM, Antonio Cuni wrote:
On 02/12/13 21:08, Philip Jenvey wrote:
It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?
Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple< (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.
another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles.
For this particular issue the suffix could be 'pypy3' instead. Though this is not ideal, should 'PyPy3' be reflected in sys.version, sys._mercurial[0], platform.python_implementation(), etc?
I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number> (2, 2).
This would be weird but I don't think it would break any version number checks, being a higher number.
-- Philip Jenvey
Just a thought: If you consider that pypy is an alternate *implementation* of the python lanaguage, ISTM the implementation should do whatever the version of the python *language* implies (2.7.3 as of now?). The version of the implementation (pypy or other) would seem to be orthogonal. No? Regards, Bengt Richter
participants (5)
-
Antonio Cuni -
Armin Rigo -
Bengt Richter -
Philip Jenvey -
Rami Chowdhury