<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 11/22/2010 8:33 AM, Guido van Rossum wrote:
<blockquote
cite="mid:AANLkTikdqnqpVAbqV6q_=ji+R_+eaPWNLL2g4gqB_Hm-@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman <a class="moz-txt-link-rfc2396E" href="mailto:v+python@g.nevcal.com"><v+python@g.nevcal.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikdqnqpVAbqV6q_=ji+R_+eaPWNLL2g4gqB_Hm-@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<br>
OK, thanks for the philosophy statement. That's what I didn't know,
being new.<br>
<br>
<blockquote
cite="mid:AANLkTikdqnqpVAbqV6q_=ji+R_+eaPWNLL2g4gqB_Hm-@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
That sounds like wishful thinking. :-)
</pre>
</blockquote>
<br>
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!<br>
</body>
</html>