Antoine Pitrou wrote: > Isaac Morland <ijmorlan <at> uwaterloo.ca> writes: >>> IMO, all these issues militate for putting __pycache__ creation out of >>> the interpreter core, and in the hands of third-party package-time/ >>> install-time tools (or distutils). >> Speaking only for myself, but really for anybody who likes tidy source >> directories, I hope some version of the __pycache__ proposal becomes part >> of standard Python, by which I ideally mean it's enabled by default but if >> that is just not a good idea then at most it should be required to set a >> command-line option to get this feature. > > This doesn't contradict by my proposal. > > What I am proposing is that the creation of __pycache__ /directories/ be put > outside of the core. It can be part of distutils, or of a separate module, or > delegated to third-party tools. It could even be as simple as > "python -m compileall --pycache", if someone implements it. > > Creation of the __pycache__ /contents/ (files inside the directory) would still > be part of core Python, but only if the directory exists and is writable by the > current process. +1 If I understand correctly, we would have the current mode as the default, and can trigger __pycache__ behavior simply by manually creating a __pycache__ directory and deleting any byte-code files in the module/program directory. I like this, it is easy to understand and can be used without messing with flags or environment variables. Ron
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4