Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #60155 > unrolled thread

Re: how to deal with deprecating API functionality in python module?

Started byBen Finney <ben+python@benfinney.id.au>
First post2013-11-21 15:23 +1100
Last post2013-11-21 15:23 +1100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: how to deal with deprecating API functionality in python module? Ben Finney <ben+python@benfinney.id.au> - 2013-11-21 15:23 +1100

#60155 — Re: how to deal with deprecating API functionality in python module?

FromBen Finney <ben+python@benfinney.id.au>
Date2013-11-21 15:23 +1100
SubjectRe: how to deal with deprecating API functionality in python module?
Message-ID<mailman.3001.1385007836.18130.python-list@python.org>
Chris Friesen <chris.friesen@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

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web