Indeed! The thing with pth files is that AFAIK they are not really thought to include there any code. Their main intention it to add additional paths. If you want to inject any customization code, you basically need to hack things around by creating a pth as:
import time;print("Code goes here");print("If you want multiple lines, use ;")
You cannot just create a “proper” file to be executed. Additionally, this makes debugging things harder, as you need to go through all pth files (most of them being legit) and inspect if any pth is actualyl executing any code. The proposal of __sitecustomize__ allows you to “move those pth files there” but also to write them in a sensible manner. As you’d write any other Python script.
Maybe I’m missing something obvious
You are not, I have not explained this properly as I came with previous context from the issue. Apologies about that.
How does this work? I’m the owner of the library “spam.py”, and I need
to customize startup to import “eggs.py”. What do I do?
They will be able to just install a custom script into __sitecustomize__ rather than using this pth file.
How do I avoid clashing with other libraries?
Great question! We can probably advise to name them after the package name. If there is general interest in this general idea we can further discuss the detail, but I think this won’t be a blocker.
What makes this different from, and better than, sitecustomize?
There is only one sitecustomize per Python installation (+usercustomize). The folder approach allows for many of this. Think of it as the tipical init.d of your OS.
When do the files under sitecustomize run?
Open for discussion as well. I’d suggest end of site.py. Just after all other site customization, as that allows for all general path changes before trying to find the __sitecustomize__ folders.
How do we disable this if needed?
I’d suggest starting with the already existing -S but we could add some further switch if you think it’s worth it.
Where can I place my sitecustomize ?
That is indeed another thing I’d be happy to discuss. There seem to be two proposals: Anything in the python path or in a site directory. sitecutzome.py does the former, pth files do the later. I personally find slightly more discoverable the latter. As user can rely on just importing it to see where files could be placed (for site, you can also just import site thought 
).
This would add considerable dir listing times to Python’s startup.
Indeed, I have to acknowledge I have not thought about this. If we go with the namespace like approach, this might get down to something like just an import if there is no __sitecustomize__. For installations that actually have the customizations, I guess it’s fair to pay the price. There is also always -S to disable site entirely. We should indeed do some measurements if the idea goes forward to see if it is even worth it.
We’ve been stuck with the “feature” ever since.