On 11/22/2010 8:33 AM, Guido van Rossum wrote: > On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman<v+python at g.nevcal.com> wrote: >> In reviewing my notes from my experimentations with CGIHTTPServer >> (Python2.6) and then http.server (Python 3.2a4), I note one behavior I >> haven't reported as a bug, nor do I know where to start to figure it out, >> other than experimentally. >> >> The experiment: launching CGIHTTPServer without environment variables, by >> the simple expedient of using a batch file to unset all the existing >> environment variables, and then launching Python2.6 with CGIHTTPServer. >> >> So it failed early: random.py fails at line 110 (Python 2.6). > What specific traceback do you get? In my copy of the code that line says > > a = long(_hexlify(_urandom(16)), 16) > > and I could just imagine that _urandom() fails for some reason to do > with the environment (it is a reference to os.urandom()), which, being > part of the C library code, might depend on the environment. > > But you're not giving enough info to debug this. Yep, that's the line. I'll have to re-run the scenario, but will do it on 3.2a4, hopefully tonight or tomorrow, to get the traceback. >> I suppose it is possible that some environment variables are used by Python >> directly (but I can't seem to find a documented list of them) although I >> would expect that usage to be optional, with fall-back defaults when they >> don't exist. > That is certainly the idea, but the fallbacks may not always be nice. > > Environment variables used by Python or the stdlib itself are supposed > to be named PYTHON<whatever> if they are Python-specific, and there's > a way to disable all of these (-E). But there are other environment > variables (HOME and PATH come to mind) that have a broader definition > and that are used in some part of the stdlib. Plus, as I mentioned, > who knows what the non-Python C library uses (well, somebody probably > knows, but I don't know of a central source that we can actually trust > across the many platforms where Python runs). OK, thanks for the philosophy statement. That's what I didn't know, being new. >> I suppose it is even possible that some Windows APIs might >> depend on some environment variables, but I expected that the registry had >> replaced such usage completely, by now, with the environment variables >> mostly being a convenience tool for batch files, or for optional, temporary >> alteration of particular settings. > That sounds like wishful thinking. :-) Well, wishful thinking from me regarding the Windows and the registry is that Windows would be better off without a registry. But it seemed like their direction was instead to do away with environment variables, but in any case, I have little idea if they've achieved it, but should have achieved something in 6.1 versions of Windows! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20101122/c0a8ac89/attachment.html>
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