PEP: import version

**Andrew Bennetts** · Jul 18 '05, 10:52 AM

Re: PEP: import version

On Thu, May 13, 2004 at 07:46:51AM +0000, Manlio Perillo wrote:
[...][color=blue]
> A possible syntax is this:
> import wxPython version '2.4'[/color]

I'd like to see versioned imports too, but it looks like a tricky problem to
me. Some questions that immediately spring to mind reading your proposal:

How would this work with from X import Y? How would this work with packages
(e.g. import X.Y.Z)?

e.g. how would you add version requirements to these statements:

from gtk import main

from twisted.web import server

For the first one, "from gtk version '2.0' import main" doesn't look too
bad.

But what about the second one -- can only top-level modules/packages have
versions? e.g. what if the "twisted.we b" package has a version that's
independent of the top-level "twisted" container package? Would "from
twisted.web version '1.3.0'" mean Twisted version 1.3.0, or Twisted Web
version 1.3.0?

What happens if the same program tries to import different (and possibly
conflicting) versions of the same module, e.g.:

import gtk version '2.0'
import gtk version '1.2'

Should an ImportError be raised? Should it succeed (assuming both versions
are available)? Is it even possible to have two different versions of the
same library/module installed in parallel, and if so, how?

I'd love to see a proposal that addresses all of these points :)
[color=blue]
> Another case is when the module is implemented also in C:
> import picke version 'C'[/color]

Alternative implementations of the same module for reasons of optimisation
is a different problem, and I don't think it's a good idea to try solve it
the same way.

-Andrew.

**Peter Otten** · Jul 18 '05, 10:52 AM

Re: PEP: import version

Manlio Perillo wrote:
[color=blue]
> A possible syntax is this:
> import wxPython version '2.4'[/color]

Why not just

import wxPython2_4 as wxPython

and a symlink or something equivalent pointing to the latest version
to also allow

import wxPython
[color=blue]
> Another case is when the module is implemented also in C:
> import picke version 'C'[/color]

Presenting the user with the choice of two equivalent modules is a mistake
IMHO. Just rename cPickle to pickle and move pickle.py into the
docs/demo/educational section. Or, more general, provide a Python version
as a fallback:

<pickle.py>
try
# try
from cPickle import *
except ImportError:
# python implementation
</pickle.py>

Peter

**David Fraser** · Jul 18 '05, 10:52 AM

Re: PEP: import version

Peter Otten wrote:[color=blue]
> Manlio Perillo wrote:
>
>[color=green]
>>A possible syntax is this:
>>import wxPython version '2.4'[/color]
>
>
> Why not just
>
> import wxPython2_4 as wxPython
>
> and a symlink or something equivalent pointing to the latest version
> to also allow
>
> import wxPython[/color]

We've been discussing different approaches to allow version import on
the wxPython list. See the wiki entry at

index.cgi/VersionSelection - wxPyWiki

http://wiki.wxpython.org/index.cgi/VersionSelection

My latest code is attached, which allows selection via command-line
parameters, assuming wxPython is installed in well-named subdirectories.
See the wxpython users list for more info

David

import os
import sys
import glob

"""wxselect selects an appropriate wxPython module and adds it to sys.path
Version selection is implemented with environment variables"
Order of precedence is:
WXPYTHON_PATH
WXPYTHON_VERSIO N (looks for a version starting with this - 2.4 or 2.4.2.4 are valid)
WXPYTHON_MINVER SION (requires at least this version)
Otherwise the latest available version is used
"""

class EnvConfig:
"""reads environment variables of the form MODULE_KEY and stores them as self.key"""
def __init__(self, modulename, keys):
for key in keys:
setattr(self, key, os.getenv("%s_% s" % (modulename.upp er(), key.upper())))

class VersionFinder:
"""Finds Versions of a module using module-x.y.z directory names and selects best match for environment variables"""
keys = ("minversion ", "version", "path", "pythonpath ")
def __init__(self, modulename, versionimportli st = None, versionattrlist = ["ver", "version", "VERSION", "VERSION_STRING "]):
"""construc t a VersionFinder for the given modulename"""
self.modulename = modulename
if versionimportli st:
self.versionimp ortlist = versionimportli st
else:
self.versionimp ortlist = [os.path.join(se lf.modulename, "__version__.py ")]
self.versionatt rlist = versionattrlist
self.findversio ns()

def findversions(se lf):
"""finds all versions of this module by looking at module-x.y.z directories in the Python Path"""
self.versions = {}
for path in sys.path:
filenames = glob.glob(os.pa th.join(path, '%s-*' % self.modulename ))
for filename in filenames:
if os.path.isfile( filename) and filename.lower( ).endswith(os.e xtsep + "pth"):
versionname = os.path.splitex t(os.path.basen ame(filename))[0]
versiondirs = open(filename). readlines()
versionpaths = []
for versiondir in versiondirs:
versionpaths.ex tend(self.readv ersionpath(vers iondir.strip()) )
elif os.path.isdir(f ilename):
versionname = os.path.basenam e(filename)
versionpaths = self.readversio npath(filename)
else:
continue
version = versionname[len("%s-" % self.modulename ):]
if version not in self.versions:
self.versions[version] = versionpaths
return self.versions

def readversionpath (self, versiondir):
"""reads any .pth files in the versiondir and returns the path required for the version"""
versionpaths = [versiondir]
versionpthfiles = glob.glob(os.pa th.join(version dir, '*.pth'))
for pthfile in versionpthfiles :
for line in open(pthfile, "r").readlines( ):
versionpath = line.strip()
if not versionpath: continue
if not os.path.isabs(v ersionpath):
versionpath = os.path.join(os .path.dirname(v ersiondir), versionpath)
versionpaths.ap pend(versionpat h)
return versionpaths

def readpathversion (self, versionpath):
"""reads the module version from the given path"""
import imp
for versionimportpa th in self.versionimp ortlist:
versionfilename = os.path.join(ve rsionpath, versionimportpa th)
if os.path.isfile( versionfilename ):
versionmodule = imp.load_source (os.path.basena me(versionfilen ame), versionfilename , open(versionfil ename, 'r'))
if versionmodule is not None:
for versionattrname in self.versionatt rlist:
version = getattr(version module, versionattrname , None)
if version is not None:
return version
return None

def getversionpath( self, version):
"""looks up the pathsep-joined path for the given version"""
return os.path.pathsep .join(self.vers ions[version])

def listversions(se lf):
"""lists known versions"""
return self.versions.k eys()

def getbestversion( self, possibleversion s):
"""finds the best version out of the possibilities"" "
if possibleversion s:
return max(possiblever sions)

def getconfig(self, path=None, version=None, minversion=None ):
"""reads the environment variables and intelligently chooses version and path"""
config = EnvConfig(self. modulename, self.keys)
if path:
config.path = path
if version:
config.version = version
if minversion:
config.minversi on = minversion
if config.path:
config.version = self.readpathve rsion(config.pa th)
else:
if config.version:
possibleversion s = [version for version in self.listversio ns() if version.startsw ith(config.vers ion)]
elif config.minversi on:
possibleversion s = [version for version in self.listversio ns() if version >= config.minversi on]
else:
possibleversion s = self.listversio ns()
config.version = self.getbestver sion(possibleve rsions)
if config.version:
config.path = self.getversion path(config.ver sion)
return config

def setpath(self, path=None, version=None, minversion=None ):
"""removes other versions from the path and appends the selected path"""
allpaths = []
map(allpaths.ex tend, self.versions.v alues())
self.removefrom path(allpaths)
config = self.getconfig( path, version, minversion)
self.appendtopa th(config.path)

def appendtopath(se lf, paths):
"""takes a pathsep-separated path list and adds elements to the Python path at the end"""
if paths:
pathlist = paths.split(os. path.pathsep)
pathlist = [path for path in pathlist if path and os.path.isdir(p ath)]
sys.path.extend (pathlist)

def prependtopath(s elf, paths):
"""takes a pathsep-separated path list and adds elements to the Python path at the beginning"""
if paths:
pathlist = paths.split(os. path.pathsep)
pathlist = [path for path in pathlist if path and os.path.isdir(p ath)]
sys.path = pathlist + sys.path

def removefrompath( self, pathlist):
"""removes all known versions from the PythonPath"""
if pathlist:
pathlist = [os.path.abspath (path) for path in pathlist if path and os.path.isdir(p ath)]
sys.path = [path for path in sys.path if os.path.abspath (path) not in pathlist]

wx25versionfile = os.path.join("w x", "__version__.py ")
wx25versionattr = "VERSION_STRING "
wx24versionfile = os.path.join("w xPython", "__version__.py ")
wx24versionattr = "wxVERSION_STRI NG"
wxversionimport list = [wx25versionfile , wx24versionfile]
wxversionattrli st = [wx25versionattr , wx24versionattr]
wxVersionFinder = VersionFinder(" wxPython", versionimportli st = wxversionimport list, versionattrlist = wxversionattrli st)

if __name__ == "__main__":
print "wxPython version selector"
print "available versions:"
for version, path in wxVersionFinder .versions.iteri tems():
print "%s: %s" % (version, path)
print
config = wxVersionFinder .getconfig()
print "selected: %s in %s" % (config.version , config.path)
else:
wxVersionFinder .setpath()
# wxVersionFinder .appendtopath(w xVersionFinder. getconfig().pat h)

**Skip Montanaro** · Jul 18 '05, 10:52 AM

Re: PEP: import version

Manlio> This, I think, can be resolved by allowing an user to explicitly
Manlio> say what version of a module it wants (sush as version numbers
Manlio> in Linux shared objects).

Manlio> A possible syntax is this:
Manlio> import wxPython version '2.4'

Somehow that version has to map to a different file being loaded, so it
seems to me the proper place to record this information is in sys.path (or
before the program runs, PYTHONPATH). Voila! No syntax changes required.

Skip

**Christopher Barker** · Jul 18 '05, 10:52 AM

Re: PEP: import version

Skip Montanaro wrote:[color=blue]
> Somehow that version has to map to a different file being loaded, so it
> seems to me the proper place to record this information is in sys.path (or
> before the program runs, PYTHONPATH). Voila! No syntax changes required.[/color]

This really needs to be done at runtime, not ahead of time with PYTHONPATH.

We have been discussing this over at wxPython-users, and a number f
workable solutions have been proposed. However, it would be great if
there was an "official" Pythonic way to do it, rather than each package
author coming up with their own system. So, I'm all for a PEP, even if
it is just for a standard approach, and no change to python whatsoever.
If someone is working on a proposal, you might want to consider these
(from the wxPython Wiki):

Basic Goals:

* Multiple versions of wxPython being installed at the same time
* Two or more programs, each using a different version could run at
once.
* Easy for developers - for testing with multiple versions etc
* Easy for users - their apps detect the right version to run with
* Cross-Platform solution

More detail:

* The ability for the programmer to specify the version used in the
code, ideally only on (or before) the first import of wxPython
* A default version that gets imported with "import wx", just like
it's always been
* The ability to specify the version wanted with an environment
variable, so that multiple versions could be easily tested
* The ability to specify multiple versions that all work, in a
ordered list of some sort.
* The ability to specify a "minimal" version, and higher versions
could be used.
* The ability for "from wx.lib import Something" to work as well,
respecting the version

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@no aa.gov

**Skip Montanaro** · Jul 18 '05, 10:53 AM

Re: PEP: import version

Chris> Skip Montanaro wrote:[color=blue][color=green]
>> Somehow that version has to map to a different file being loaded, so
>> it seems to me the proper place to record this information is in
>> sys.path (or before the program runs, PYTHONPATH). Voila! No syntax
>> changes required.[/color][/color]

Chris> This really needs to be done at runtime, not ahead of time with
Chris> PYTHONPATH.

Chris> We have been discussing this over at wxPython-users,

Perhaps I'm missing something... If you need to futz around at runtime,
futz around with sys.path. Can you summarize the wxPython discussions for
those of us who don't use that toolkit (and have apparently never run into
this problem in such an intractable way that we felt the need to change
Python because of it)? In particular it would be helpful to understand why
you don't know what version of wxPython you want to use before running the
program.

Thanks,

Skip

**Skip Montanaro** · Jul 18 '05, 10:53 AM

Re: PEP: import version

Chris> Basic Goals:

Chris> * Multiple versions of wxPython being installed at the same time

Presumably in different directories, so setting PYTHONPATH, LD_LIBRARY_PATH ,
etc will distiguish them for applications.

Chris> * Two or more programs, each using a different version could run
Chris> at once.

This doesn't require a change to the language. This requires a proper
setting of PYTHONPATH and/or LD_LIBRARY_PATH , etc.

Chris> * Easy for developers - for testing with multiple versions etc

That's fine, and precludes the use of something like a hardcoded

import wxPython version '2.4'

as someone else suggested. In fact, this just cries out for either a
WXPYTHON_VERSIO N environment variable which the wxPython framework could use
or for setting PYTHONPATH.

Chris> * Easy for users - their apps detect the right version to run
Chris> with

Getting the right version of dependent packages is an installation issue.
This should be detectable from either configure script, Makefile or
distutils setup.py script.

Chris> * Cross-Platform solution

Distribute your apps with .bat file front ends on Windows, shell scripts
on Unix.

Chris> More detail:

Chris> * The ability for the programmer to specify the version used in
Chris> the code, ideally only on (or before) the first import of
Chris> wxPython

I fail to understand why that's a problem that needs to be addressed in the
Python program. This is information which is know before the program is
run. It belongs in an environment variable or front-end shell/bat script.

Chris> * The ability to specify the version wanted with an environment
Chris> variable, so that multiple versions could be easily tested

This is the correct way to do this.

Chris> * The ability to specify multiple versions that all work, in a
Chris> ordered list of some sort.

Your installation program should detect all installed versions and pick the
latest version which intersects with the set of multiple working versions.

Chris> * The ability to specify a "minimal" version, and higher versions
Chris> could be used.

Again, this goes in your setup.py script (or configure, or Makefile, or
whatever). It's an install-time decision.

Chris> * The ability for "from wx.lib import Something" to work as well,
Chris> respecting the version

Assuming your installation software worked correctly this should be a
no-brainer. ;-)

Skip

**Christopher Barker** · Jul 18 '05, 10:53 AM

Re: PEP: import version

Skip Montanaro wrote:
[color=blue]
> Perhaps I'm missing something... If you need to futz around at runtime,
> futz around with sys.path. Can you summarize the wxPython discussions for
> those of us who don't use that toolkit (and have apparently never run into
> this problem in such an intractable way that we felt the need to change
> Python because of it)?[/color]

Actually, I was personally advocating an approach that did not require
changing python, but would hopefully be standardized. I posted a
question to this newsgroup about it a short while back, and I think
PyGTK and PMW both do this in some way or another, so it's not a totally
unique problem.
[color=blue]
> In particular it would be helpful to understand why
> you don't know what version of wxPython you want to use before running > the program.[/color]

I know what version I want when writing it, but not necessarily when
running it. This is analogous to why I ALWAYS use:

#!/usr/bin/env python2.3

rather than:

#!/usr/bin/env python

at the top of my scripts. RedHat doing the later created a major
pain-in-the-behind for many of us. I only wish there were a way for
Windows Python to handle that kind of thing gracefully. MacPython uses a
"PythonLauncher " mini-app to take care of it (and for other reasons).

Anyway, as for wxPython (and many other packages, I imagine), I have a
handful of small utilities that work just fine with Python version X and
wxPython version Y. If I upgrade python while keeping the old one in
place, they all still work (thanks to my specifying the version on the
#! line), However, if I add wxPython version Z, I'm stuck. The way it's
ordinarily installed is in site-packages/wx. If I do a standard install,
it blows away version Y, and all my existing programs are broken. What
I, and other "early adopters" of new versions do is do a custom install
and run a script that re-names or sym-links site-packages/wx to the
version we want. That helps, but then at any given moment, only one is
the active version, so I can't run a new and old program at the same
time. So what some of us would like is for the standard way that
wxPython is installed to allow for versioning. The Wiki page pointed to
earlier has some suggestions about how to do this.

[color=blue]
> Chris> Basic Goals:
> Chris> * Multiple versions of wxPython being installed at the same time[/color]

[color=blue]
> Presumably in different directories, so setting PYTHONPATH, LD_LIBRARY_PATH ,
> etc will distiguish them for applications.[/color]

Well, yes, but unfortunately, the standard install puts it in
site-packages, so you have to do a custom install to make this work.
[color=blue]
> Chris> * Two or more programs, each using a different version could run
> Chris> at once. This doesn't require a change to the language. This requires a proper
> setting of PYTHONPATH and/or LD_LIBRARY_PATH , etc.[/color]

Well, yes, but that's a PITA that I don't want to have to go through. I
want to be able to distribute apps also, and not everyone is going to
have the same paths as me, and certainly not the same on different OSs.
[color=blue]
> Chris> * Easy for developers - for testing with multiple versions etc
>
> That's fine, and precludes the use of something like a hardcoded
>
> import wxPython version '2.4'[/color]

No, it doesn't. Change the 2.4 to 2.5 and you test again. However, there
have been requests for:
[color=blue]
> a
> WXPYTHON_VERSIO N environment variable which the wxPython framework could use
> or for setting PYTHONPATH.[/color]

yup, that's one option, but good for developers, not good for users.
[color=blue]
>
> Chris> * Easy for users - their apps detect the right version to run
> Chris> with[/color]

[color=blue]
> Getting the right version of dependent packages is an installation issue.
> This should be detectable from either configure script, Makefile or
> distutils setup.py script.[/color]

Actually this is poorly worked, I don't want the app to detect anything,
I want to to specify something:

import wx-2_5 as wx

for instance.
[color=blue]
> Chris> * Cross-Platform solution
>
> Distribute your apps with .bat file front ends on Windows, shell scripts
> on Unix.[/color]

Yuck, yuck yuck! First of all, I don't know a .bat from a hole in the
ground (though I suppose I need to learn this to deal with python
versioning anyway..sigh), and second of all, I'd much rather not have to
write a wrapper script around a twenty line utility script (or a 2000
line one either!), and third of all, the wrapper script would be
platform and individual system dependent
[color=blue]
> Chris> * The ability for the programmer to specify the version used in
> Chris> the code, ideally only on (or before) the first import of
> Chris> wxPython[/color]

[color=blue]
> I fail to understand why that's a problem that needs to be addressed in the
> Python program. This is information which is know before the program is
> run. It belongs in an environment variable or front-end shell/bat script.[/color]

A front-end script script is one solution to these problems, but it's
another layer I would rather not have to deal with! Another issue is for
OS_X BundleBuilder Bundles. You can build them to use the Python
installation, so I'd like to be able to to the version specifying inside
the python script, not outside of it.
[color=blue]
> Chris> * The ability to specify the version wanted with an environment Chris> variable, so that multiple versions could be easily tested
>
> This is the correct way to do this.[/color]

It is ONE way to so it, not THE way.
[color=blue]
> Chris> * The ability to specify multiple versions that all work, in a Chris> ordered list of some sort.
> Your installation program should detect all installed versions and pick the
> latest version which intersects with the set of multiple working versions.[/color]

Again, simple solutions for simple problems. I don't want to write a
complex installer. Frankly, I think this is getting too fancy (though it
would be nice). I'm just as happy to have my apps Require a particular
version, that way I know I've tested there. Disk space it cheap.
[color=blue]
> Chris> * The ability to specify a "minimal" version, and higher versions Chris> could be used.
>
> Again, this goes in your setup.py script (or configure, or Makefile, or
> whatever). It's an install-time decision.[/color]

Again with the installer! What's wrong with dropping a script in
/usr/local/bin? Granted when you get beyond small utilities, there is
often a need for a proper installer, but in that case, you could be
building stand alone apps with PY2EXE or whatever anyway.
[color=blue]
> Chris> * The ability for "from wx.lib import Something" to work as well, Chris> respecting the version[/color]

[color=blue]
> Assuming your installation software worked correctly this should be a
> no-brainer. ;-)[/color]

This was addressing why you couldn't just do:

import wx-2_5 as wx

because then you'd have to change all the "wx" to "wx-2-2_5" everywhere
else which could get ugly. One thing that makes this harder, at least
for wxPython, is that there is a legacy way that wxPython has been
installed and imported, and people would like to preserve that, so that

import wx

and

from wx.lib import Something

and

import wx.lib.Somethin g

need to all still work.

By the way, as my thought about this started with wxPython, and now I'm
advocating a more general solution, I realize there are some
differences. A big one is that you could never use more than one version
of wxPython in a single program, but you might very well be able to use
multiple versions of other packages in the same program. So, while for
wxPython it makes sense for __main__ to specify the wxPython version,
and all other modules that "import wx" get than version, this may not be
the case with other packages, where each module using it might want a
different version.

This is really analogous to shared libraries. I see a Python package as
no different to a shared lib in function. When you compile and link and
app, the version of the shared lib is specified. When it is run, the
linker looks for an links that version. The user doesn't have to set an
environment variable first, or change the lib path, or anything else.
All I'm looking for is that same functionality. Does anyone remember the
old DOS days of DLL hell? why would we want that? (Is Windows any better
now? I'm wouldn't know)

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@no aa.gov

**A. Lloyd Flanagan** · Jul 18 '05, 10:54 AM

Re: PEP: import version

Christopher Barker <Chris.Barker@n oaa.gov> wrote in message news:<c80v79$h2 o$1@news.nems.n oaa.gov>...[color=blue]
> differences. A big one is that you could never use more than one version
> of wxPython in a single program, but you might very well be able to use
> multiple versions of other packages in the same program. So, while for[/color]

Using multiple versions in one program sounds like a recipe for
disaster to me, even with some sort of language support. Also, we
shouldn't make the normal single-version case more complex or less
efficient to support a case that should be extremely rare.

**Christopher Barker** · Jul 18 '05, 10:55 AM

Re: PEP: import version

A. Lloyd Flanagan wrote:[color=blue]
> Using multiple versions in one program sounds like a recipe for
> disaster to me, even with some sort of language support. Also, we
> shouldn't make the normal single-version case more complex or less
> efficient to support a case that should be extremely rare.[/color]

This is a tricky one. I was just suggesting that while it is clear that
for wxPython, you'd NEVER be able to run more than one version, that
possibility should be considered for other packages. I'm imagining a
module that uses a given package and version for some internal purpose.
A user of that module may have no idea what packages it is using, and
may happen to want to use the same package, different version. Unless
data types from that package are being passed between he two versions,
this could certainly work.

However, you may be right that this is a recipe for disaster, and the
user of that module simply needs to test with the version they are
using,a nd if it fails, get an updated version of the module, so that
the whole program is using the same versions of everything.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@no aa.gov

**Christophe Cavalaria** · Jul 18 '05, 10:55 AM

Re: PEP: import version

Manlio Perillo wrote:
[color=blue]
> Hi.
> I'm a new user of Python but I have noted a little problem.
> Python is a very good language but it is evolving, in particular its
> library is evolving.
> This can be a problem when, ad example, a module change its interface
> or its implementation in a fundamental way (an example: wxPython).
> This, I think, can be resolved by allowing an user to explicitly say
> what version of a module it wants (sush as version numbers in Linux
> shared objects).
>
> A possible syntax is this:
> import wxPython version '2.4'[/color]

I would say that the fault is on wxWindow and their constantly mutation API.
A good API should be compatible whit older programs with each minor
revision ( with only a few changes here and there if needed ) and would get
a new name for each major revision.

**Hung Jung Lu** · Jul 18 '05, 10:55 AM

Re: PEP: import version

Christopher Barker <Chris.Barker@n oaa.gov> wrote in message news:<c82sjs$qv m$1@news.nems.n oaa.gov>...[color=blue]
> A. Lloyd Flanagan wrote:[color=green]
> > Using multiple versions in one program sounds like a recipe for
> > disaster to me, even with some sort of language support. Also, we
> > shouldn't make the normal single-version case more complex or less
> > efficient to support a case that should be extremely rare.[/color]
>
> However, you may be right that this is a recipe for disaster, and the
> user of that module simply needs to test with the version they are
> using,a nd if it fails, get an updated version of the module, so that
> the whole program is using the same versions of everything.[/color]

It all depends on the specific problem. The need for heteroversion
applications becomes important in client-server architecture. For
various reasons (business, technical, or otherwise), clients may not
be updated immediately with each new release. Thus, the server needs
to handle requests with legacy I/O formats and/or with legacy business
logic. If well-done, heteroversion components can ensure a smooth
transition in upgrades. In long-running server processes, you really
would like to be able to switch dynamically between different versions
during runtime.

In principle, if a package is well-written as a heteroversion
application, then you could do something like:

import myPackage
myPackage.use_v ersion('2.3')
.... do tasks a la version 2.3
myPackage.use_v ersion('2.4')
.... do tasks a la version 2.4

Traditionally, Windows DLLs have a rudimentary way of implementing
heteroversion features: by creating more and more API interfaces,
while preserving the old code to make them backward-compatible. Thus a
new DLL is supposed to work in new and old versions of the OS.
Although theoretically sound, in practice this approach requires
high-degree of discipline. Therefore you get the well-known "DLL hell
problem". Microsoft has kind of decided that disk space is no longer a
concern, and has opted for independent assemblies for each version in
the DotNet world. Price to pay: if there is a bug that is carried over
several versions, you'll probably have to (1) work it through the
source code files of each version, creating branches (2) release
upgrades for different older versions. Instead of developing software
in time dimension alone, you now have a two-dimensional problem. This
two-dimensional problem should be well-known to people that release
software packages in multiple versions.

There is no perfect solution, no free lunch. Each approach (single
heteroversion application, or multiple versioned packages) has its own
benefits and problems.

But if the heteroversion approach is wanted, there are ways to do it.
Inheritance polymorphism is just one of the tools.

regards,

Hung Jung

**Manlio Perillo** · Jul 18 '05, 10:56 AM

Re: PEP: import version

On Thu, 13 May 2004 18:07:27 +1000, Andrew Bennetts
<andrew-pythonlist@puzz ling.org> wrote:
[color=blue]
>On Thu, May 13, 2004 at 07:46:51AM +0000, Manlio Perillo wrote:
>[...][color=green]
>> A possible syntax is this:
>> import wxPython version '2.4'[/color]
>
>I'd like to see versioned imports too, but it looks like a tricky problem to
>me. Some questions that immediately spring to mind reading your proposal:
>
>How would this work with from X import Y? How would this work with packages
>(e.g. import X.Y.Z)?
>
>e.g. how would you add version requirements to these statements:
>
> from gtk import main
>[/color]

I see a simple solution:
from gtk version '2.0' import main

It should be up to gtk root module (ex __init__.py) to decide what
version of sub modules to load.

[color=blue]
>But what about the second one -- can only top-level modules/packages have
>versions? e.g. what if the "twisted.we b" package has a version that's
>independent of the top-level "twisted" container package? Would "from
>twisted.web version '1.3.0'" mean Twisted version 1.3.0, or Twisted Web
>version 1.3.0?
>[/color]

The sub-level packages have version too.
In example:

twisted version 1.3.0 -> web version 1.1
twisted version 1.3.5 -> web version 1.1
twisted version 1.4.0 -> vew version 1.2

The right sub module version to load is decided by the top level
module.

In detail (using a single file for all versions):
__init__.py

if __version__ == '1.4.0':
__all__ = [ ('web', '1.2'),
...
]
elif __version__ == '1.3.5':
_all = [ ('web', '1.1'),
...
]

That is, the items of __all__ should be tuples.
[color=blue]
>What happens if the same program tries to import different (and possibly
>conflicting) versions of the same module, e.g.:
>
> import gtk version '2.0'
> import gtk version '1.2'
>[/color]
[color=blue]
>Should an ImportError be raised? Should it succeed (assuming both versions
>are available)? Is it even possible to have two different versions of the
>same library/module installed in parallel, and if so, how?[/color]

It should unload gtk version 2.0 and load the version 1.0

Regards Manlio Perillo

**David Fraser** · Jul 18 '05, 10:58 AM

Re: PEP: import version

Christophe Cavalaria wrote:[color=blue]
> Manlio Perillo wrote:
>
>[color=green]
>>Hi.
>>I'm a new user of Python but I have noted a little problem.
>>Python is a very good language but it is evolving, in particular its
>>library is evolving.
>>This can be a problem when, ad example, a module change its interface
>>or its implementation in a fundamental way (an example: wxPython).
>>This, I think, can be resolved by allowing an user to explicitly say
>>what version of a module it wants (sush as version numbers in Linux
>>shared objects).
>>
>>A possible syntax is this:
>>import wxPython version '2.4'[/color]
>
>
> I would say that the fault is on wxWindow and their constantly mutation API.
> A good API should be compatible whit older programs with each minor
> revision ( with only a few changes here and there if needed ) and would get
> a new name for each major revision.[/color]

Have you actually used it extensively? If so, I doubt you would be
saying this...
wxWiindows (now wxWidgets) doesn't have aconstantly mutating API.
But the new major revision does have some changes. The point is you can
still get programs to work with both versions, so you don't need to have
a new name. But if a program does rely on a particular version, it would
be nice to have a way to specify it.

David

PEP: import version

PEP: import version

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment