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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
