In test_fileio, one of the tests wants to ensure writing to closed raw streams fails, but it actually tries to write an unicode string, which should rather lead to an immediate TypeError.

Here is a tiny patch to prevent the "double error cause" danger - this test is bugging me because my own I/O library cant pass the stdlib io tests in this case.

The initial problem here is that we can't write unicode to a buffered binary stream (TypeError), but we can do it with an unbufferred raw stream - as the C implementation of the latter does string coercion instead of raising TypeError.
Shouldn't we unify the behaviour of binary streams in such cases ?

> The initial problem here is that we can't write unicode to a buffered 
> binary stream (TypeError), but we can do it with an unbufferred raw 
> stream - as the C implementation of the latter does string coercion 
> instead of raising TypeError.
> Shouldn't we unify the behaviour of binary streams in such cases ?

Yes, we certainly should. This is probably an oversight or a bug.

Allright, what's the expected behaviour then - implicitly converting unicode to bytes (like C RawFileIO), or raising a typeerror (like buffered streams do) ?

> Allright, what's the expected behaviour then - implicitly converting
> unicode to bytes (like C RawFileIO), or raising a typeerror (like
> buffered streams do) ?

Sorry, I should have been clearer. The expected behaviour is to raise a
TypeError. The new io module was written for Python 3, where you
shouldn't mix bytes and unicode strings and expect things to work.

This would require patching separately py2k and py3k visibly...
I'll have a look at it when I have time.

pakal wrote:
"""
In test_fileio, one of the tests wants to ensure writing to closed raw streams fails, but it actually tries to write an unicode string
"""

I don't understand. Isn't b'xxx' and 'xxx' the same in py2.x? They are not unicode string, but bytes string.

yes, but the same tests are used for py3k as well, where "xxx" is interpreted as unicode (2to3 tools dont try to guess if a py2k string intended to be a byte string or an unicode one).

test_fileio and test_io both use "from __future__ import unicode_literals", which means classical string literals construct unicode strings rather than byte strings.
So, yes, Pascal is right, this should be corrected (both the tests, and the implementation so that it refuses unicode arguments).

Yes, I saw that, thanks for explanation!

So I work a patch against the trunk, including modification of fileio_write(), bufferedwriter_write() and test_fileio.py.

Amaury, do you remember if we made this deliberately?

The 3.1 version does it correctly since issue7785, but this was not backported to 2.x.
Python 3.x uses the "y*" format code to accept bytes and not unicode; this code does not exist in 2.x, and was replaced with "s*", which accepts unicode.
But since the io module is designed up front to forbid default conversion between bytes and unicode, I think it's safe to change the code as suggested.

I agree, that it would be right to accept only binary strings when write to binary stream. But I afraid that it is too late to change this in the 16th bugfix of 2.7. This can break existing code or tests.

I suggest to change the behavior only in the Py3k compatibility mode. PR 11127 is based on issue_8765.diff, but emits a warning when run Python with the -3 option.

$ ./python -3 -c "import io; io.FileIO('/dev/null', 'w').write(u'')"
-c:1: DeprecationWarning: write() argument must be string or buffer, not 'unicode'
$ ./python -3 -We -c "import io; io.FileIO('/dev/null', 'w').write(u'')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
DeprecationWarning: write() argument must be string or buffer, not 'unicode'

This will help to migrate to Python 3, but keeps the behavior unchanged in normal run.

New changeset 1462234baf7398a6b00c0f51905e26caa17d3c60 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-8765: Deprecate writing unicode to binary streams in Py3k mode. (GH-11127)
https://github.com/python/cpython/commit/1462234baf7398a6b00c0f51905e26caa17d3c60