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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4