This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients brett.cannon, christian.heimes, eric.snow, lemburg, minrk, ncoghlan, paul.moore, r.david.murray, tdsmith, vstinner
Date 2015-07-02.13:51:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CACac1F_=zkWNuYJiozzV2x-5HQ-BZsYPqse=cKUpciC0Rp5AZg@mail.gmail.com>
In-reply-to <55931878.2000402@egenix.com>
Content
On 30 June 2015 at 23:30, M.-A. Lemburg <mal@egenix.com> wrote:
> I don't remember the details of why this feature was added,
> but can imagine that it was supposed to enable installation
> of new importers via .pth files.

I don't know for certain if this feature was already available when
importers were added, but there was certainly never any thought of
adding importers via .pth files when we designed them. We expected
importers to be added to sys.(meta_)path by explicit code run at
application startup, before the imports that needed it.

I'm glad to hear that setuptools is reconsidering its import priority
hacking. And I also have never seen any use of executable code in .pth
files that wasn't at best a dubious hack. But removing the feature (as
opposed to getting packages to stop misusing the feature) is too much
of a compatibility break.

It might be worth putting together a documentation patch that expands
what the docs say about the feature. Pointing out that it's easy to
misuse, and advising caution, might be a reasonable thing to do.
(Adding an example of a reasonable use of the feature would be even
better, but that would require thinking of a reasonable use!!! :-))
History
Date User Action Args
2015-07-02 13:51:09paul.mooresetrecipients: + paul.moore, brett.cannon, ncoghlan, vstinner, christian.heimes, r.david.murray, eric.snow, minrk, tdsmith
2015-07-02 13:51:09paul.moorelinkissue24534 messages
2015-07-02 13:51:08paul.moorecreate