Hi, tracking the commit log I have noticed for Windows there was added a new feature which is very interesting and can also be useful for other platforms. If I read it right it supports adding a sys.path text file near the executable to specify the Python sys.path variable and overwriting the default behavior. https://hg.python.org/cpython/rev/03517dd54977 This change is only for Windows (if I read right). But I think it is thus valuable to add this in common as general rule. This also simplifies and unifies virtual environment creating and standalone redistribution. Also I have one remaining question, is the "*.pth" file handling then disabled by this feature? If yes, can this be a problem in a virtual environment if a package uses a pth file installed in the virtual environment site-packages directory? Overall I think this is a great addition and the start to unify sys.path handling. And a good feature for redistribution of a Python interpreter without an installation. (Embedding, virtual environments, fat virtual environments, ...) Regards, Wolfgang
On 10 September 2016 at 18:37, Wolfgang <tds333@mailbox.org> wrote:
Hi,
tracking the commit log I have noticed for Windows there was added a new feature which is very interesting and can also be useful for other platforms.
If I read it right it supports adding a sys.path text file near the executable to specify the Python sys.path variable and overwriting the default behavior.
While I'm all for adding ways to simplify CPython sys.path configuration, they shouldn't be added as implicit side effects of other changes without at least some discussion of the chosen approach. If there isn't time for that, and it's needed to solve a particular problem, then the underscore-prefix naming convention indicating "this is not a standardised and supported interface" works just as well for config files as it does for module and attribute names. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
The underscore is an appropriate rename here, but calling the file sys.path was too juicy :) It's intended only for embedding on Windows and does not exist on Linux/Mac yet (more precisely, implementation is only in PC/getpathp.c). I chatted with some people about spreading it and there wasn't really enough interest yet - theoretical uses but not actual ones, whereas on Windows there are actual uses. If you have actual uses we can look more seriously at it, but right now it's more of a secret registry key that disables the registry. As it is totally outside the language and very specific to a particular installation, support can easily be added at any time. Find my various write-ups on the embeddable distro for details on the use cases, but none of them affect regular Python developers. Cheers, Steve Top-posted from my Windows Phone -----Original Message----- From: "Nick Coghlan" <ncoghlan@gmail.com> Sent: 9/10/2016 2:43 To: "Wolfgang" <tds333@mailbox.org> Cc: "Python Dev" <python-dev@python.org> Subject: Re: [Python-Dev] sys.path file feature On 10 September 2016 at 18:37, Wolfgang <tds333@mailbox.org> wrote:
Hi,
tracking the commit log I have noticed for Windows there was added a new feature which is very interesting and can also be useful for other platforms.
If I read it right it supports adding a sys.path text file near the executable to specify the Python sys.path variable and overwriting the default behavior.
While I'm all for adding ways to simplify CPython sys.path configuration, they shouldn't be added as implicit side effects of other changes without at least some discussion of the chosen approach. If there isn't time for that, and it's needed to solve a particular problem, then the underscore-prefix naming convention indicating "this is not a standardised and supported interface" works just as well for config files as it does for module and attribute names. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
participants (3)
-
Nick Coghlan -
Steve Dower -
Wolfgang