For debugging reasons I have added a simple line to PyObject_Call()
function in Objects/abstract.c:
printf("%s.%s\n", func->ob_type->tp_name, PyEval_GetFuncName(func));
Now, after compiling python and running interpreter with simple
print() call I receive this:

Python 3.0a1 (py3k, Nov  6 2007, 19:25:33)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('!',end='')
builtin_function_or_method.print
method.write
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
function.closed
!method.write   # here it goes again for 'end' parameter
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
builtin_function_or_method.displayhook
>>>

Note that there can be something going on between one function.closed 
and the next one, because not every piece of code gets called by 
PyObject_Call(), but still - isn't it checking if stream is closed a 
bit too often?

Regards,
Wojtek Walczak

The problem should be addressed after the last alpha during the
optimization and cleanup phase.

To find out what really happens, use pdb to step through the example.
This gives much better insight than adding a printf() call to
PyObject_Call(). I've notice myself when stepping through I/O that there
are a lot of checks for closed -- this may have to do with the stacking
text -> buffer -> binary though. I've also noticed overridden isinstance
checks in abc.py being called, which surprised me slightly. I haven't
had time to look into this further though.

Is this issue still valid?

I reproduce almost the same output.
"function.closed" often come in pair, because TextIOWrapper.closed is a
property which delegates to self.buffer.closed

I think that the first check in TextIOWrapper.write() is not necessary:
self.buffer.write(b) will also check for "self.buffer.closed", and there
is not much code in-between. The only side-effect is the decoder state.

Does io in C help with this?

Closing, as I don't think there's any point trying to micro-optimize the
Python version.