[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/)