python file versioning

[kartik]

2 enable non-backward compatible changes to be made to the language or
the standard library (or other libraries, for that matter), i feel
there should be a way to version python files. the current __future__
system suffers from changing behaviour in the absence of the imports,
from version to version of the interpreter. this means that i can't
simply run a python file without knowing which version of the
interpreter it was developed against.

with such a versioning system, non-backward compatible changes can be
made to libraries without breaking code. (the __future__ mechanism
seems to cover only the language)

at some time in the future (not __future__!), we could allow
side-by-side execution of different versions of libraries on the same
interpreter.

-kartik

 

[Diez B. Roggisch]

You can always have conditional imports based on the interpreter version
like this:

import sys

if sys.version_info[:2] == (2,2):
from __future__ import nifty_feature


And you can extend that to class definitions and the like, too. And
import-hooks might help, too.

 

[Jeff Epler]

No, that's completely incorrect.

File "/tmp/diez.py", line 4
from __future__ import nifty_feature
SyntaxError: from __future__ imports must occur at the beginning of the file

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBfQxNJd01MZaTXX0RAilaAJ0bYVM2PZQ4lEXdmyZ9mjJNZZ3V4gCfSo+2
a/3Z9Zs/SeE5HV34c/R4ALE=
=HgAw
-----END PGP SIGNATURE-----

 

[Jeff Epler]

There's sure to be a lot of time required to properly implement this.

If you really want a feature like this to be included in Python, then
you should study Python well enough to know what it would take to
implement it, write a PEP, and show that there is community interest in
the feature. Then you'd better be prepared to contribute the
implementation.

Personally, I find that the ability to have multiple Python interpreter
versions installed on the same system (/usr/local/bin/pythonX.Y) along
with the usually-excellent forward compatibility of old source code to
be an ample security blanket...

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBfQ6fJd01MZaTXX0RArQEAJwNPWR3873K2oQYIJeWzijSP7WEIwCdFudK
nWOp9OSWTefdYFGdfSBe0Nk=
=KjFM
-----END PGP SIGNATURE-----

 

[Diez B. Roggisch]

No, that's completely incorrect.

File "/tmp/diez.py", line 4
from __future__ import nifty_feature
SyntaxError: from __future__ imports must occur at the beginning of the
file

Oops - I didn't know that. But it makes sense - as it possibly affects
parsing behaviour it has to be like that.

But _completely_ is a bit strong - other version-dependend code can be
written like that, and if you encapsulate the version depenend code in
modules, you can still import them like this:


file mod_22:
from __future__ import nifty_feature
import bar

file mod_23:
import bar


app.py:

import sys

if sys.version_info[:2] == (2,2):
import mod_22 as mod
else:
import mod_23 as mod


So I think I showed the OP a way to deal with version-dependencies.

 

[kartik]

file mod_22:
from __future__ import nifty_feature
import bar

file mod_23:
import bar


app.py:

import sys

if sys.version_info[:2] == (2,2):
import mod_22 as mod
else:
import mod_23 as mod


So I think I showed the OP a way to deal with version-dependencies.

that's a quite a bit of work. i'm talking about automating this

 

[Timothy Fitz]

file mod_22:

from __future__ import nifty_feature
import bar

file mod_23:
import bar

app.py:

import sys

if sys.version_info[:2] == (2,2):
import mod_22 as mod
else:
import mod_23 as mod

No need for all of that, from __future__ import feauture becomes a
no-op if you use it on a version that already has the feature (for
instance, from __future__ import generators)

 

[Diez B. Roggisch]

that's a quite a bit of work. i'm talking about automating this

The whole task of having one codebase support several languange versions is
tedious - i strongly doubt that these few lines of code are the hard part.

And if you want more automation, you can also use input-hooks. The could be
used to import a module version-dependend by looking for a name convention.
There has been discussions on loading modules over the net recently, I'm
sure google might help you here.