On 26Aug2017 0842, Steve Dower wrote:
Is there going to be a visible flag or anything to know you're running a restricted version of Python? If so then a subclass will allow us to override get_code() so that it just skips .pyc files and it can be used automatically when the flag is set. That way users of spython don't have to think about setting that up. Otherwise we could provide a function in importlib._bootstrap that you call during initialization to turn this on.
The idea is that importlib and similar code should just use open_for_exec when they’re opening files that will be executed, and let the hook (if any) worry about validating extensions. The overridden function is needed because as you said, there’s currently one open call that is used for opening both code and data files, and for data files it should just use regular open(). The override can just be permanently there, since with no hook there’s no difference. (And custom subclasses may also need updating, which gets back to “if you don’t control the code that’s running then none of these protections will protect you” and you have to rely on audit hooks.)
And thinking through how to avoid this being trivially bypassed (spoiler - it'll always be trivial) has led to adding more audit hooks for monkeypatching (set __bases__, set __class__, type.__setattr__, etc.). Those could also be useful as debugging/coverage tools, and the sort of thing you'd use a Python hook for in test code to see what nasty things are being done by your dependencies, even if you have no intention of tracking them in production. But between those, a simple isinstance(self, SourceLoader) in FileLoader, and guidance in the PEP, I don't think there's any value in investing too heavily in preventing people from doing `FileLoader.get_data = my_get_data` (which at least requires multiple lines of Python code, compared to `del SourceFileLoader.get_data` if using a simple override). Cheers, Steve