On 25 November 2016 at 12:26, Robert Collins <robe...@robertcollins.net> wrote: > On 25 November 2016 at 14:04, Nick Coghlan <ncogh...@gmail.com> wrote: >> The bad reputation of ".pth" doesn't generally stem from their normal >> usage (i.e. just listing absolute or relative directory names that the >> import system will then append to __path__). >> >> Rather, it stems from this little aspect: "Lines starting with import >> (followed by space or tab) are executed." (from >> https://docs.python.org/3/library/site.html ) > > I think its also worth exploring a targeted, modern namespace aware > replacement.
Right. For a long time I thought "existing .pth files, only with the import line execution deprecated" was the only approach that stood any chance whatsoever of being adopted in a reasonable time frame, but we can technically use the "executable .pth file" trick ourselves to let people opt in to a new sys.path extension format on earlier Python versions. > That is - there are two, related, use cases for .pth files vis-a-vis > package installation. One is legacy namespace packages, which AFAICT > are still in use - the migration is "complicated". The second is > arguable a variant of that same thing: putting the current working dir > into the PYTHONPATH without putting it in PYTHONPATH. Third case: making zip archive contents available to applications without unpacking the archive first. > The former case may be sufficiently covered by (forget the pep #) that > we don't need to do anything, PEP 420, and I believe the only thing that can get tricky there now is figuring out how to do things in such a way that they work with both old-style namespace packages and the automatic Python 3 ones. > and the latter is certainly something > that we should be able to deliver without needing the turing complete > capability that you're suggesting. Something data driven rather than > code driven. While I agree with this, I think there's two pieces to it: - how to handle the data-driven use cases that we're entirely fine with - how to handle the arbitrary-code-execution use cases that we'd like to discourage, but don't want to make entirely impossible The problem with proposing an entirely new implicit path manipulation format is that if we deprecate ".pth" files entirely, then that hits *both* of those groups equally, while if we don't deprecate them at all, then neither group has an incentive to migrate to the new system. By contrast, if we only propose deprecating "import" lines in ".pth" files, and also propose a more explicit approach to automatic code execution at interpreter startup, then it's only folks relying on the arbitrary-code-execution feature that would incur any migration costs. The language level pay-offs to justify that cost would be: - simplification of the current systems for implicit code execution at start-up - making ".pth" files less dangerous as a format Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
