how to deal with deprecating API functionality in python module?

[Ben Finney]

Chris Friesen <chris.friesen at windriver.com> writes:

> I'm pretty new to python, I'm trying to figure out how a python module
> is supposed to make non-backwards-compatible changes without blowing
> up the applications that use it.

The short answer is that Python doesn't have a library linker, so we do
it through co-operative APIs and bundled third-party libraries, rather
than versioned linking to shared libraries.

> How would something like this work in a python application?  I don't
> see any way to do the equivalent of
>
> import foo version X

You can have the library expose a ‘foo.version’ attribute (or,
sometimes, a ‘foo.__version__’ attribute) and have the library user
check for that. Ideally, make its value a tuple of integers (as Python
does for its run-time version) so the library user can choose the level
of precision it will match.

Sadly, there's no way to have multiple versions of a library with the
same name installed and available to the same application.

You'll probably receive advice to install all your application's
dependencies together in a so-called “virtualenv” with the application.

This is dreadful practice – it ignores the OS package managed libraries,
it requires every deployment to manage dependencies separately, it
promotes needless duplication and potentially divergent code, it makes
security updates a nightmare, etc. – but it appears to be the best
Python has for this, given the lack of a versioned linking feature.

-- 
 \     “The trouble with the world is that the stupid are cocksure and |
  `\             the intelligent are full of doubt.” —Bertrand Russell |
_o__)                                                                  |
Ben Finney