Versioning Libraries

[Randall Smith]

As Python changes and old code still needs to work properly, I wonder if
there is a standard way to note which version of the Python interpreter
code is intended to work with. I know that an executable may begin with
#!/usr/bin/python2.3 or something similar, but what about libraries and
such? Would it be a good idea for the software I write to check for the
version of the interpreter?

Randall Smith

 

[Peter Hansen]

As Python changes and old code still needs to work properly, I wonder if
there is a standard way to note which version of the Python interpreter
code is intended to work with. I know that an executable may begin with
#!/usr/bin/python2.3 or something similar, but what about libraries and
such? Would it be a good idea for the software I write to check for the
version of the interpreter?

Python is exceptionally backwards compatible, so generally
code from an older version will run unchanged on newer
Pythons.

There is a simple way of encoding a version of the interpreter,
but the real question is why would you want to do that. If
you really think it's necessary, just import sys and check the
value of sys.version_info. Lots of code which wants to require
a *minimum* version of Python (a far more common use case than
checking for a *maximum*) contains code like this:

import sys
if sys.hex_version[:3] < (2, 3, 3):
sys.exit('Requires Python 2.3.3 or later to run!')


-Peter

 

[Bryan]

As Python changes and old code still needs to work properly, I wonder
if there is a standard way to note which version of the Python
interpreter code is intended to work with. I know that an executable
may begin with #!/usr/bin/python2.3 or something similar, but what
about libraries and such? Would it be a good idea for the software I
write to check for the version of the interpreter?

Python is exceptionally backwards compatible, so generally
code from an older version will run unchanged on newer
Pythons.

There is a simple way of encoding a version of the interpreter,
but the real question is why would you want to do that. If
you really think it's necessary, just import sys and check the
value of sys.version_info. Lots of code which wants to require
a *minimum* version of Python (a far more common use case than
checking for a *maximum*) contains code like this:

import sys
if sys.hex_version[:3] < (2, 3, 3):
sys.exit('Requires Python 2.3.3 or later to run!')


-Peter

i think you meant something this:

>>> import sys
>>> sys.version_info[:3] (2, 4, 0)
>>> sys.version_info[:3] >= (2, 3, 3)

True

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: 'module' object has no attribute 'hex_version'

bryan

 

[Richard Brodie]

Python is exceptionally backwards compatible, so generally
code from an older version will run unchanged on newer
Pythons.

I'm just curious: why exceptionally? I like Python for a lot of
reasons but I wouldn't put API stability high on the list.
Not compared with a traditional language like C or Fortran,
anyway. Which languages go around breaking backwards
conmpatibility in a cavalier way?

 

[Peter Hansen]

I'm just curious: why exceptionally? I like Python for a lot of
reasons but I wouldn't put API stability high on the list.
Not compared with a traditional language like C or Fortran,
anyway. Which languages go around breaking backwards
conmpatibility in a cavalier way?

Anything from Microsoft, for a start.

Anyway, you're confusing "instability" (I hate that word,
it has connotations of unreliability, which aren't intended)
with "enhancement". The API gets changed, yes, but by
adding new things, almost never by removing the old stuff
or changing how it works. You are free to ignore the new
stuff, and almost all old code will work unchanged. That's
what backwards compatibility means, not that no new features
are ever added.

-Peter

 

[Simon Brunning]

I'm just curious: why exceptionally? I like Python for a lot of
reasons but I wouldn't put API stability high on the list.
Not compared with a traditional language like C or Fortran,
anyway. Which languages go around breaking backwards
conmpatibility in a cavalier way?

VB, for a start. <http://www.mvps.org/vb/index2.html?rants/vfred.htm>

 

[Richard Brodie]

Anyway, you're confusing "instability" (I hate that word,
it has connotations of unreliability, which aren't intended)
with "enhancement". The API gets changed, yes, but by
adding new things, almost never by removing the old stuff
or changing how it works.

I'm not confusing it, I'm disagreeing. Take xreadlines, for
example. Added in 2.1, deprecated in 2.3, removed in 2.4
Perhaps I lead a sheltered life but that's almost infinitely
worse than any other language I have used. It's not a big
issue though: I'm just surprised that what I would regard as
a weakness in Python, others consider a strength.