Oh, and by the way, there can be a race condition between __pycache__ creation and deletion (if it fails the test), where an attacker can stuff a hostile pyc file in the directory in the meantime (and the deletion then fails because the directory isn't empty). 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). Le Mon, 22 Mar 2010 14:30:12 +0000, Antoine Pitrou a écrit : > > __pycache__ should only be created if explicitly activated (for example > by distutils when installing stuff). Otherwise, if not present, the > "legacy" mechanism (writing an untagged pyc file along the py file) > should be used. > > Actually, __pycache__ creation doesn't have to be part of the import > mechanism. It can be part of distutils instead (or whatever third-party > tool such as distribute, or distro-specific packaging scripts). This > would relax complexity of core Python a bit. > > Regards > > Antoine.
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