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]

Re: Versioning Libraries

Randall Smith wrote:[color=blue]
> 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?[/color]

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_inf o. 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('Requi res Python 2.3.3 or later to run!')


-Peter

[Peter Hansen]

Re: Versioning Libraries

Randall Smith wrote:[color=blue]
> 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?[/color]

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_inf o. 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('Requi res Python 2.3.3 or later to run!')


-Peter

[Bryan]

Re: Versioning Libraries

Peter Hansen wrote:[color=blue]
> Randall Smith wrote:
>[color=green]
>> 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?[/color]
>
>
> 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_inf o. 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('Requi res Python 2.3.3 or later to run!')
>
>
> -Peter[/color]

i think you meant something this:
[color=blue][color=green][color=darkred]
>>> import sys
>>> sys.version_inf o[:3][/color][/color][/color]
(2, 4, 0)[color=blue][color=green][color=darkred]
>>> sys.version_inf o[:3] >= (2, 3, 3)[/color][/color][/color]
True
[color=blue][color=green][color=darkred]
>>> sys.hex_version[/color][/color][/color]
Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
AttributeError: 'module' object has no attribute 'hex_version'

bryan

[Bryan]

Re: Versioning Libraries

Peter Hansen wrote:[color=blue]
> Randall Smith wrote:
>[color=green]
>> 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?[/color]
>
>
> 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_inf o. 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('Requi res Python 2.3.3 or later to run!')
>
>
> -Peter[/color]

i think you meant something this:
[color=blue][color=green][color=darkred]
>>> import sys
>>> sys.version_inf o[:3][/color][/color][/color]
(2, 4, 0)[color=blue][color=green][color=darkred]
>>> sys.version_inf o[:3] >= (2, 3, 3)[/color][/color][/color]
True
[color=blue][color=green][color=darkred]
>>> sys.hex_version[/color][/color][/color]
Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
AttributeError: 'module' object has no attribute 'hex_version'

bryan

[Richard Brodie]

Re: Versioning Libraries


"Peter Hansen" <peter@engcorp. com> wrote in message news:coog1l$mip $1@utornnr1pp.g rouptelecom.net ...
[color=blue]
> Python is exceptionally backwards compatible, so generally
> code from an older version will run unchanged on newer
> Pythons.[/color]

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?

[Richard Brodie]

Re: Versioning Libraries


"Peter Hansen" <peter@engcorp. com> wrote in message news:coog1l$mip $1@utornnr1pp.g rouptelecom.net ...
[color=blue]
> Python is exceptionally backwards compatible, so generally
> code from an older version will run unchanged on newer
> Pythons.[/color]

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]

Re: Versioning Libraries

Richard Brodie wrote:[color=blue]
> "Peter Hansen" <peter@engcorp. com> wrote in message news:coog1l$mip $1@utornnr1pp.g rouptelecom.net ...
>
>[color=green]
>>Python is exceptionally backwards compatible, so generally
>>code from an older version will run unchanged on newer
>>Pythons.[/color]
>
>
> 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?[/color]

Anything from Microsoft, for a start.

Anyway, you're confusing "instabilit y" (I hate that word,
it has connotations of unreliability, which aren't intended)
with "enhancemen t". 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

[Peter Hansen]

Re: Versioning Libraries

Richard Brodie wrote:[color=blue]
> "Peter Hansen" <peter@engcorp. com> wrote in message news:coog1l$mip $1@utornnr1pp.g rouptelecom.net ...
>
>[color=green]
>>Python is exceptionally backwards compatible, so generally
>>code from an older version will run unchanged on newer
>>Pythons.[/color]
>
>
> 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?[/color]

Anything from Microsoft, for a start.

Anyway, you're confusing "instabilit y" (I hate that word,
it has connotations of unreliability, which aren't intended)
with "enhancemen t". 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]

Re: Versioning Libraries

On Fri, 3 Dec 2004 11:03:58 -0000, Richard Brodie <r.brodie@rl.ac .uk> wrote:
[color=blue]
> 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?[/color]

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

--
Cheers,
Simon B,
simon@brunningo nline.net,

http://www.brunningonline.net/simon/blog/

[Simon Brunning]

Re: Versioning Libraries

On Fri, 3 Dec 2004 11:03:58 -0000, Richard Brodie <r.brodie@rl.ac .uk> wrote:
[color=blue]
> 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?[/color]

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

--
Cheers,
Simon B,
simon@brunningo nline.net,

http://www.brunningonline.net/simon/blog/

[Richard Brodie]

Re: Versioning Libraries


"Peter Hansen" <peter@engcorp. com> wrote in message news:copjeg$t25 $1@utornnr1pp.g rouptelecom.net ...
[color=blue]
> Anyway, you're confusing "instabilit y" (I hate that word,
> it has connotations of unreliability, which aren't intended)
> with "enhancemen t". The API gets changed, yes, but by
> adding new things, almost never by removing the old stuff
> or changing how it works.[/color]

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.

[Richard Brodie]

Re: Versioning Libraries


"Peter Hansen" <peter@engcorp. com> wrote in message news:copjeg$t25 $1@utornnr1pp.g rouptelecom.net ...
[color=blue]
> Anyway, you're confusing "instabilit y" (I hate that word,
> it has connotations of unreliability, which aren't intended)
> with "enhancemen t". The API gets changed, yes, but by
> adding new things, almost never by removing the old stuff
> or changing how it works.[/color]

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.