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/2002-February/019983.html below:

[Python-Dev] Order that site-packages is added to sys.path

[Python-Dev] Order that site-packages is added to sys.pathMartin v. Loewis martin@v.loewis.de
12 Feb 2002 10:39:44 +0100
barry@zope.com (Barry A. Warsaw) writes:

> So the question is: why does site.py append site-packages instead of
> prepending it to sys.path?

I think the rationale was that you are precisely not supposed to
override any of the standard modules. It was considered a good thing
that if you do "import string" in some version of Python, you know
exactly what you will get.

There is currently one exception to that rule, which is the xml module
and PyXML: the standard xml module allows being replaced by add-on
(later, better) packages. However, there have been complaints that
this is so: One of Paul Prescod's applications would break if PyXML
was installed, since PyXML performed some stricter argument checking
in certain cases. 

The same problem would occur more frequently if you have site-packages
in front of the path: The add-on package may behave worse than the
standard package in some cases (especially after installing a Python
bugfix release); this problem is hard to track.

In the specific case, I'd propose the following strategy:
- Get the fixes to the Email package into the 2.2 maintainance branch,
  in addition to getting them into the trunk. This assumes that the
  patches really do fix bugs and are suitable for the general public
  etc.

- If Python 2.2.1 is released before Mailman 2.1, you are done: Just
  tell your users that they need 2.2.1 or 2.1.2, but cannot use 2.2
  (or need to live with limitations in MIME processing).

- If this is not possible, rename the email package inside mailman
  (e.g. xemail).
  It then appears that the standard library package is not suitable
  for mailman, so just ignore its presence, and use your own (under a
  different name). 

- As a compromise, you might consider falling back to the email
  package if you determine it is good enough at installation time, by
  playing with xemail.__init__.__path__, or even replacing xemail with
  email in the same way that xml is replaced with _xmlplus.

Regards,
Martin



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