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 __Vano
Recipients Anthony Sottile, Antony.Lee, Ivan.Pozdeev, __Vano, barry, brett.cannon, christian.heimes, eric.smith, eric.snow, ethan smith, mhammond, ncoghlan, pitrou, takluyver, terry.reedy
Date 2018-11-13.03:30:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> I’m a little concerned about this approach because it means random third party modules can affect the global environment for your application, without knowing it.  Since the hook installation happens at import time, and just depending on a library that has such a .pth file will install it, the end application will not have control over its global state.
But "affecting the global environment for your application" is exactly 
what is intended here. You want multiple packages to all load their code 
into the same namespaces (aka module objects), thus of course 
potentially affecting/overriding each other's functionality. That's what 
you get when you have plugins -- a badly-written/incompatible plugin can 
and will break your app.

It doesn't have to "just depend on a library that has such a .pth file", 
it's up to the import hook's implementation. I just gave as example the 
simplest solution that requires zero effort on the main package 
maintainer's part.

E.g. you can only allow adding a new submodule by default, or require 
the "parent" package to "allow" insertions into itself, or move 
registration into the parent's configuration file (so the user needs to 
enable the plugin manually), or provide some more granular code 
injection techniques like e.g. event handler lists that certain plugins' 
functions will be added into. All that matters here is that the hook is 
going to automagically assemble the resulting namespaces from parts upon 

Finally, Python applications don't have full control over their global 
state anyway. Any module can monkey-patch or override any other module 
via a variety of means. So, this risk is not something new or unexpected.
Date User Action Args
2018-11-13 03:30:58__Vanosetrecipients: + __Vano, mhammond, barry, brett.cannon, terry.reedy, ncoghlan, pitrou, eric.smith, christian.heimes, eric.snow, takluyver, Antony.Lee, Ivan.Pozdeev, Anthony Sottile, ethan smith
2018-11-13 03:30:58__Vanolinkissue33944 messages
2018-11-13 03:30:58__Vanocreate