I’m wondering if it wouldn’t be a better if Python would store the compiled code in a file stream of the original source file. This would work on file systems supporting forks/data-streams, and fall-back if this is not possible.
- On Windows using ADS (Alternative Data Streams)
- On OS X using resource forks
- On Linux using extended file attributes if compiled file is under 32k
Doing this will solve the problem of polluting the source tree or having problems like after the removal of a .py the .pyc remained and was loaded and used.
What do you think about this, sounds like a good idea or not? What issues to do see.
You sure do sacrifice an awful lot of portability this way — right now
.pycfiles are uncommonly portable (often used by heterogeneous systems on a LAN through some kind of network file system arrangement, for example, though I’ve never been a fan of the performance characteristics of that approach), while your approach would only work on very specific filesystems and (I suspect) never across a network mount on heterogenous machines.So, it would be a dire mistake to make the behavior you want the default one — but it would surely be neat to have it as an option available for specific request if your deployment environment doesn’t care about all of the above issues and does care about some of those you mention. Another “cool option to have”, that I would actually use about 100 times more often, is to put the
.pyc“files” in a database instead of having them in filesystems.The cool thing is that this is (relatively) easily accomplished as an add-on “import hack” one way or another (depending on Python versons) — most easily in recent-enough versions with importlib, Brett Cannon’s masterpiece (but that might make backporting to older Python versions harder than other ways… too much depends on exactly what versions you need to support, a detail which I don’t see in your Q, so I won’t go into the implementation details, but the general idea doesn’t change much across implementations).