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, Chris Billington, Ivan.Pozdeev, Peter L3, SilentGhost, __Vano, barry, brett.cannon, cheryl.sabella, christian.heimes, eric.smith, eric.snow, ethan smith, ionelmc, jaraco, mhammond, ncoghlan, pitrou, steve.dower, takluyver, terry.reedy, veky
Date 2019-03-01.17:27:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 01.03.2019 3:58, Steve Dower wrote
> Import hooks can always be injected by a package before the importer will try and resolve the module, so nothing is needed there.

I thought the flaw in this reasoning in was obvious and didn't want 
to bother people refuting it. Apparently not.

To do anything in, that itself needs to be 
already importable. This very well may not be the case -- in fact, 
import hooks were designed specifically for the scenarios where this is 
not the case.

Imagine e.g. loading modules from a cloud storage (why not?) -- so 
nothing on the system at all except the hook. Or, suggested earlier in 
this ticket, a union namespace where the code to import needs to be 
constructed on the fly.

> .pth files really only satisfy the "run at startup because I'm a dependency of something that my user wants and don't make them opt-in to my changed behaviour"

Startup code (custom or not) is not a dependency of anything. It rather customizes the environment in which the program specified by the user would run, _before_ any user code could be allowed to get control. It is not a part of the program to be run but rather of the environment that the user wants, and it needs to be implicit so the user can use the same commands and code (compare venv). This is a required feature because the stock Python startup logic cannot possibly provide all the customizations that a user may need (compare initrd).

.pth's are equivalent to sitecustomize but allow the user to manage the set of code chunks automatically using the packaging infrastructure (compare .d directories in UNIX). The fact that this feature is mixed up with and often supplements "real packages" that a program would explicitly use is actually incidental: a package with a .pth does not need to have any functionality intended for explicit use.

> which I don't like 

If you don't like something, there's always a specific reason -- though you may not understand it consciously. So the way to go is dig into it, find out what specific speck is putting you off -- only then can you be sure that you are concentrating on the right thing and won't throw the baby out with the bathwater. Try to change one trait in your mind's eye leaving all else intact -- will the feeling go away? If it will, you are on the right track; can the trait you chose be split further? You know you found it when you can't change any further part and change the feeling and you can say with confidence how exactly what it's doing misaligns with your moral compass.

We already identified a few real reasons: hard to see, hard to debug, encourages unreadable code, run in arbitrary order when the order matters (and IIRC I provided fixes for all). What else?
Date User Action Args
2019-03-01 17:27:23__Vanosetrecipients: + __Vano, mhammond, barry, brett.cannon, terry.reedy, jaraco, ncoghlan, pitrou, eric.smith, christian.heimes, ionelmc, SilentGhost, eric.snow, takluyver, steve.dower, veky, Ivan.Pozdeev, Anthony Sottile, ethan smith, cheryl.sabella, Chris Billington, Peter L3
2019-03-01 17:27:23__Vanolinkissue33944 messages
2019-03-01 17:27:23__Vanocreate