In IDLE, sys.stdout.write and sys.stderr can write any pickleable object such as 100 when they should only allow strings.
IDLE seems to be pickling the object.
>>> import sys
>>> sys.stdout.write(100)
100
>>> sys.stdout.write(sys)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    sys.stdout.write(sys)
_pickle.PicklingError: Can't pickle <class 'module'>: attribute lookup builtins.module failed
The error above is more detailed in IDLE 2.7.
While in Python on the command-line:
>>> import sys
>>> sys.stdout.write(100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int
>>> 
The error above in Python 2.7:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object

Why do you think this is a bug? Is this behavior causing problems?

It is different behaviour than usual.
I agree it is of low importance.

We should like the IDLE shell to give the same results as the standard shell. See #7163

On 3.2.2 on Win7, the problem is worse: sys.stdout.write(100) crashes IDLE -- as in it just fades away after a short (1/2 sec?) delay.
 sys.stdout.write(sys)
gives me the error reported.

The difference comes from this in the Command Window:
>>> sys.stdout
<_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp437'>

versus this in IDLE:
>>> import sys
>>> sys.stdout
<idlelib.rpc.RPCProxy object at 0x00000000031D0208>

The crash can be prevented by using #13582.

The RPCProxy object would need to be subclassed so that it raises TypeError for the "write" method when it is not given a string.

> We should like the IDLE shell to give the same results as the standard shell. 

I disagree that this should be an absolute principle. Two standard
shells may not give the same result due to running in different
environments, so forcing IDLE to give the same result as a specific
standard shell is not reasonable when taken absolutely.

In English, "We should like" is far from an absolute statement. "IDLE must" would be such. In any case, I hope you agree that crashing is bad. It is also not good if IDLE, as a development environment, enables code that violates the doc specifications and that will not run in the standard interpreter in standard batch mode with no shell.

I also so not understand you reverting the title to the arguably incorrect non-parallel construction.

> I also so not understand you reverting the title to the arguably incorrect non-parallel construction.

That is an (unfortunate) side effect of replying by email.

One reason to fix this bug:

People may develop code that calls sys.std{out,err}.write with the number 200.
like sys.stdout.write(200)
In IDLE the code works well but in Python from the command-line it fails to run.
Creating a bug in the code.

This bug is related to #1757057.

What is the status of this bug?
It has been about two months since the last message.

Many issues take a while, depending on volunteers time and choice of priority.

Ramchandra: Most likely, the status is that nobody is working on this, and nobody is planning to work on this. So if you want to see it fixed, it may be that you have to submit a patch yourself.

Attached is a preliminary patch to solve this issue. It relies on "rpc_marshal_exception.patch" from issue14200. 

Does anyone know a good way to make the exception render as: "must be str, not int" instead of "must be str, not <class 'int'>" ?

Just a minor comment on the patch - It should be %r instead of %s.

-            raise TypeError('must be str, not %s' % type(s))
+            raise TypeError('must be str, not %r' % type(s))

If there is any test for this, it could be added. I find this approach 'OK'.

@Roger Serwy
>> Does anyone know a good way to make the exception render as: "must be str, not int" instead of "must be str, not <class 'int'>" ?
Use s.__name__ rather than type(s) for the type name
e.g.
-raise TypeError('must be str, not %s' % type(s))
+raise TypeError('must be str, not %s' % s.__name__)

@Ramchandra: "__name__" does not exist for many objects.

This issue with the sys.stdout.write encompasses a lot of other issues involving the shortcomings of the RPCProxy object. The following code prevents another prompt from appearing:

    >>> class A:
            pass

    >>> import sys
    >>> sys.stdout.write(A)

Even though "A" is pickleable, IDLE gets stuck trying to write to stdout. In run.py, Executive.runcode gets stuck on "exec(code, self.locals)", and is not interruptable. Restarting the shell makes the IDLE shell responsive again to commands.

> Does anyone know a good way to make the exception render as: "must be str, not int" instead of "must be str, not <class 'int'>" ?

raise TypeError('must be str, not %s' % type(s).__name__)

> The following code prevents another prompt from appearing:

And this a more serious issue concerns 3.3.

The patch (to my production Idle, with name fix) prevents crashing and raises an error instead when an object *can* be pickled, so I will apply before 3.3 if no problems appear and we cannot do better.

But written objects are still pickled, so sys.stdout.write(sys) still raises the PicklingError instead of (as in CP interpreter)
  TypeError: must be str, not module

It seems to me that the type check should be done in the subprocess before the object (which should be a string) is pickled. (I also wonder if it is really necessary to pickle a string or the encoded bytes to send it back. The pickle is just a stream of bytes.)

New changeset 422242dbce30 by Martin v. Löwis in branch '3.2':
Issue #13532: Check that arguments to sys.stdout.write are strings.
http://hg.python.org/cpython/rev/422242dbce30

New changeset 58189e37331c by Martin v. Löwis in branch '2.7':
- Issue #13532: Check that arguments to sys.stdout.write are strings.
http://hg.python.org/cpython/rev/58189e37331c

All problems in computer science can be solved by another indirection...

I've added another wrapper around the RPC proxy to cause the type error. (A variant of) Roger's patch is still included to support the -n case.

I just pulled Martin's patches and they fix the issue. Indirection to the rescue!

There is one very slight problem though with the error message raised on 2.7 since it is different than 3.3. Attached is a patch to fix it.

Ah, this indicates that we should support any buffer object...

Thanks Martin. I was thinking of adding special-casing inside the rpcproxy class, but the wrapping is pretty clean and clear. Works great in 3.3 Win7-64.

The 2.7 message 'expected a character buffer object' is technically correct*, but opaque, especially to beginners. I actually prefer the 3.x style message, except that 'str' should be expanded to 'string'. (We especially should not say 'character buffer object' until we test for exactly that.)

*My impression is that 2.7 unicode is not a character buffer object, but gets auto converted to str/bytes, which is.

On the technically correct front, bytearray in 2.7 is a character buffer object that .write() can write, but it is not a subclass of basestring. So the widened test in the followup patch
http://hg.python.org/cpython/rev/2993f566c82e
should be widened further.

-        if not isinstance(s, basestring):
-             raise TypeError('must be str, not ' + type(s).__name__)

+        if not isinstance(s, (basestring, bytearray)):
+             raise TypeError('must be string, not ' + type(s).__name__)

Are there any other 'character buffer' classes that should be included? What *is* the test that 2.7 .write() uses to determine what is such? Can it even be written in Python (rather than C)?

I'm losing interest in this issue. It already got more attention than it deserves. Terry, feel free to make whatever change you consider desirable.

New changeset 4f891f44ec15 by Terry Jan Reedy in branch '2.7':
Issue 13532: Allow bytearrays to be written also.
http://hg.python.org/cpython/rev/4f891f44ec15

I tested and pushed the change to allow bytestrings. If anyone is printing other character buffer objects in 2.7 with Idle, they can explicitly convert to str/bytes, patch run.py, and/or post here or on a new issue for further expansion. I am otherwise done with this too.

> +        sys.stdin = self.console = _RPCFile(self.get_remote_proxy("stdin"))

write to sys.stdin?

sys.stdin has a write method, but it should raise "io.UnsupportedOperation: not writable" when passed a string. It looks like IDLE has allowed writes to stdin even before Martin's patch. I'll open a separate issue for this case.

Running "input" from IDLE now raises an error. Attached is a fix to _RPCFile to allow readline (and isatty) to function properly.

>>> sys.stdin.readable()
False
>>> sys.stdout.writable()
False

I think the issue is far from a solution.

Folks: one issue at a time - pretty pretty please.

This issue was "In IDLE, sys.stdout and sys.stderr can write any pickleable object". Will anybody dispute that this issue is fixed?

Roger: please create a new issue for input being broken now. Your patch "shouldn't" be necessary, as __getattr__ should deal with this.

Serhiy: please create a new issue for readable and writable returning an incorrect result.