While trying to configure an in-package Python interpreter I found that the interpreter still uses 'string.py' as landmark for finding the standard library. Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
While trying to configure an in-package Python interpreter I found that the interpreter still uses 'string.py' as landmark for finding the standard library.
Oops.
Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location.
I don't see a need for a new strategy, but I'll gladly accept patches that look for os.py. Note that there are several versions of that code: Modules/getpath.c, PC/getpathp.c, PC/os2vacpp/getpathp.c. --Guido van Rossum (home page: http://www.python.org/~guido/)
[MAL]
Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location. [GvR] I don't see a need for a new strategy
I'll argue for (a choice of) new strategy. The getpath & friends code spends a whole lot of time and energy trying to reverse engineer things like developer builds and strange sys-admin pranks. I agree that code shouldn't die. But it creates painful startup times when Python is being used for something like CGI. How about something on the command line that says (pick one or come up with another choice): - PYTHONPATH is *it* - use PYTHONPATH and .pth files found <here> - start in <sys.prefix>/lib/python<sys.version[:3]> and add PYTHONPATH - there's a .pth file <here> with the whole list - pretty much any permutation of the above elements The idea being to avoid a few hundred system calls when a dozen or so will suffice. Default behavior should still be to magically get it right. - Gordon
[MAL]
Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location. [GvR] I don't see a need for a new strategy
I'll argue for (a choice of) new strategy. The getpath & friends code spends a whole lot of time and energy trying to reverse engineer things like developer builds and strange sys-admin pranks. I agree that code shouldn't die. But it creates painful startup times when Python is being used for something like CGI.
How about something on the command line that says (pick one or come up with another choice): - PYTHONPATH is *it* - use PYTHONPATH and .pth files found <here> - start in <sys.prefix>/lib/python<sys.version[:3]> and add PYTHONPATH - there's a .pth file <here> with the whole list - pretty much any permutation of the above elements
The idea being to avoid a few hundred system calls when a dozen or so will suffice. Default behavior should still be to magically get it right.
I'm not keen on changing the meaning of PYTHONPATH, but if you're willing and able to set an environment variable, you can set PYTHONHOME and it will abandon the search. If you want a command line option for CGI, an option to set PYTHONHOME makes sense. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
[Gordon]
[MAL]
Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location. [GvR] I don't see a need for a new strategy
I'll argue for (a choice of) new strategy.
I'm not keen on changing the meaning of PYTHONPATH, but if you're willing and able to set an environment variable, you can set PYTHONHOME and it will abandon the search. If you want a command line option for CGI, an option to set PYTHONHOME makes sense.
The routines will still look for the landmark though (which is what surprised me and made me look deeper -- setting PYTHONHOME didn't work for me because I had only .pyo files in the lib/python1.5 dir). Perhaps Python should put more trust into the setting of PYTHONHOME ?! [An of course the landmark should change to something like os.py -- I'll try to submit a patch for this.] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
[me]
I'm not keen on changing the meaning of PYTHONPATH, but if you're willing and able to set an environment variable, you can set PYTHONHOME and it will abandon the search. If you want a command line option for CGI, an option to set PYTHONHOME makes sense.
[MAL]
The routines will still look for the landmark though (which is what surprised me and made me look deeper -- setting PYTHONHOME didn't work for me because I had only .pyo files in the lib/python1.5 dir).
Perhaps Python should put more trust into the setting of PYTHONHOME ?!
Yes! Note that PC/getpathp.c already trusts PYTHONHOME 100% -- Modules/getpath.c should follow suit.
[An of course the landmark should change to something like os.py -- I'll try to submit a patch for this.]
Maybe you can combine the two? --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Gordon McMillan -
Guido van Rossum -
M.-A. Lemburg