In pythonrun.c, initstdio injects 'open' into builtins. However,
initsite is called before initstdio and site.py uses open.
Running with -v, this traceback is printed:

Traceback (most recent call last):
  File "j:\python30\lib\site.py", line 518, in <module>
main()
  File "j:\python30\lib\site.py", line 501, in main
known_paths = addsitepackages(known_paths)
  File "j:\python30\lib\site.py", line 281, in addsitepackages
addsitedir(sitedir, known_paths)
  File "j:\python30\lib\site.py", line 178, in addsitedir
addpackage(sitedir, name, known_paths)
  File "j:\python30\lib\site.py", line 141, in addpackage
f = open(fullname, "rU")
NameError: global name 'open' is not defined

This happens if the site-packages directory contains a .pth file.

This was unnoticed because the usual message
'import site' failed; use -v for traceback
is never printed: sys.stderr is empty before the call to initstdio().

Attached patch writes the "'import site' failed" message to libc stderr
instead of sys.stderr, which does not exist at this point.

The initial problem still remains: site.py cannot use the "open" builtin.

We could:

1. Use _fileio._FileIO directly.
2. Use os.open.
3. Initialize the stdio streams before importing site. This seems like
   the best option, although I haven't run all the tests yet.

Here's my patch for the problem.

Well, it would be interesting to know why r62778 has exactly the
opposite move.
Alexandre, do you remember doing it?

It was probably done so that importing _bytesio would actually work in
io. IMO, it would be better to just compile _bytesio and _stringio into
the python binary.

Benjamin is right. site.py imports the io module before _bytesio and
_stringio are available for import. Thus the python version of BytesIO
and StringIO is always used. There is an old thread about the issue at
http://mail.python.org/pipermail/python-3000/2007-December/011569.html

As for compiling _bytesio and _stringio into the main binary, you should
ask python-dev or python-3000.

On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
<report@bugs.python.org> wrote:

Benjamin Peterson <musiccomposition@gmail.com> added the comment:

We could:

1. Use _fileio._FileIO directly.
2. Use os.open.
3. Initialize the stdio streams before importing site. This seems like
   the best option, although I haven't run all the tests yet.

Or you could use _warnings which is already compiled into the binary.

On Mon, Aug 25, 2008 at 12:48 PM, Brett Cannon <report@bugs.python.org> wrote:

Brett Cannon <brett@python.org> added the comment:

On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> We could:
>
> 1. Use _fileio._FileIO directly.
> 2. Use os.open.
> 3. Initialize the stdio streams before importing site. This seems like
> the best option, although I haven't run all the tests yet.
>

Or you could use _warnings which is already compiled into the binary.

How would that help the problem of site using open() when it can't?

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue3279\>

---

--
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

On Mon, Aug 25, 2008 at 10:49 AM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> On Mon, Aug 25, 2008 at 12:48 PM, Brett Cannon <report@bugs.python.org> wrote:
>>
>> Brett Cannon <brett@python.org> added the comment:
>>
>> On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
>> <report@bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>>>
>>> We could:
>>>
>>> 1. Use _fileio._FileIO directly.
>>> 2. Use os.open.
>>> 3. Initialize the stdio streams before importing site. This seems like
>>> the best option, although I haven't run all the tests yet.
>>>
>>
>> Or you could use _warnings which is already compiled into the binary.
>
> How would that help the problem of site using open() when it can't?
>>

Sorry, replied to the wrong email. It was meant as a reply to Amaury's
suggestion of writing out a comment that importing site failed to
stderr.

IMO, it's unacceptable to be running Python code before the stdio
streams are set up. I believe that moving the site initialization after
the setting up the streams isn't as big a problem because the dynlibs
are on sys.path before site is run when python is installed. See
bpo-586680. I will write to Python-dev.

Here's a patch that builds _bytesio and _stringio right into the binary.
I think Windows build files will need to be updated, though.

Windows build files will need to be updated
Nothing to do here: they are already built-in, linked into Python30.dll,
and listed in PC/config.c

But shouldn't the two extension modules be removed from setup.py?

Yes, indeed.

Look good to me, and python-dev accepted the patch. So, go ahead and
commit it.

Fixed in r66239.