A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-July/090663.html below:

[Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

[Python-Dev] [Distutils] PEP 376 - from PyPM's point of viewR. David Murray rdmurray at bitdance.com
Wed Jul 15 18:49:57 CEST 2009
On Wed, 15 Jul 2009 at 16:14, Paul Moore wrote:
> Bluntly, as Python stands, import and sys.path do not offer any core
> support for multiple versions. Custom solutions can be built on top of
> that - that's what setuptools does. But they are precisely that -
> custom solutions, and should be supported as such, outside the core
> (and stdlib).
>
> If standard Python support for multi-version imports is required (it's
> not by me, but I accept that some people want it), then it should be
> designed in thoughout:

Isn't this problem directly analogous to the '.so version' (*) problem?
Can we learn anything from the solution to that problem?  Does not the
fact that a (standard) solution to that problem was required indicate
that a similar solution needs to be provided by core Python?  (And yes,
it's out of scope for PEP 376).

--David

(*) or, for our Windows users, DLL Hell and the Side By Side Component
Sharing solution...
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4