[Python-Dev] Python version numbers and mac OS X
Guido van Rossum
guido@python.org
Fri, 17 Aug 2001 08:24:36 -0400
I think the crux here lies in the definitions of compatible and
incompatible changes. You give some examples of incompatible changes:
> (remove a routine, add a parameter to an existing routine, change a
> structure)
and some examples of compatible changes:
> (adding a routine, that sort of thing)
Unfortunately, there's a vast area of possible changes that aren't
really covered by these. An example from recent c.l.py discussions:
in Python 2.2a1, changed dir(). I didn't change the signature (it
still returns a sorted list of strings), but I changed what it returns
in some cases: dir([]) used to return ['append', 'count', ...]; in
2.2a1 it returns []. That was deemed incompatible. Interesting
enough, making it return a *longer* list of strings is deemed
compatible! I'm sure it's easy to find examples in C as well.
The moral of the story: a compatible version doesn't guarantee much
beyond compatible linkage -- whether the application still works
depends on a lot more than can be expressed by a minor version number.
> I don't have a solution for this yet, mainly because the incrementing
> of the API version number hasn't always been completely fair to the
> last iota and tittle. For instance, the change of the list.append()
> semantics should really have incremented the API version number, but I
> don't think it did.
Interesting point. For me, the API version number only describe the
*C* API version, not the Python API. In this case, at least the
combination (python version, C API version) did change.
> If we could be sure that a newer Python core shared library could work
> together with an older Python Lib directory (as long as the API
> versions matched) and would provide at least the functionality of that
> older Python version we would be fine: use the API version number in
> the pathname and use the real version number in the lib/python2.2 and
> such.
While this could work, but it would be confusing: sys.version would be
the version of the core shared library, and applications would expect
to find the corresponding Lib modules. IOW, I don't think it's a
useful feature to have.
--Guido van Rossum (home page: http://www.python.org/~guido/)