Skip to content

In IDLE, sys.stdout and sys.stderr can write any pickleable object #57741

Closed
Closed
In IDLE, sys.stdout and sys.stderr can write any pickleable object#57741
Labels
topic-IDLEtype-crashA hard crash of the interpreter, possibly with a core dump

Description

@RamchandraApte
RamchandraApte
mannequin
opened on Dec 5, 2011
BPO 13532
Nosy @loewis, @terryjreedy, @orsenthil, @serwy, @serhiy-storchaka
Files
  • stdout_fix1.diff
  • issue13532_27.patch
  • stdin_fix.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2012-07-10.18:38:56.361>
created_at = <Date 2011-12-05.14:07:42.625>
labels = ['expert-IDLE', 'type-crash']
title = 'In IDLE,\tsys.stdout and sys.stderr can write any pickleable object'
updated_at = <Date 2012-07-10.18:38:56.348>
user = 'https://bugs.python.org/RamchandraApte'

    bugs.python.org fields:

    activity = <Date 2012-07-10.18:38:56.348>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2012-07-10.18:38:56.361>
closer = 'loewis'
components = ['IDLE']
creation = <Date 2011-12-05.14:07:42.625>
creator = 'Ramchandra Apte'
dependencies = []
files = ['24789', '26333', '26342']
hgrepos = []
issue_num = 13532
keywords = ['patch']
message_count = 34.0
messages = ['148873', '148889', '148907', '149361', '149370', '149459', '149470', '149475', '149490', '150075', '155285', '155291', '155295', '155411', '155440', '162527', '162645', '164286', '164287', '165062', '165107', '165108', '165110', '165112', '165123', '165124', '165125', '165129', '165130', '165168', '165189', '165191', '165194', '165197']
nosy_count = 7.0
nosy_names = ['loewis', 'terry.reedy', 'orsenthil', 'roger.serwy', 'python-dev', 'Ramchandra Apte', 'serhiy.storchaka']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue13532'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

    Activity

    1. RamchandraApte commented on Dec 5, 2011

      @RamchandraApte
      RamchandraAptemannequin
      on Dec 5, 2011
      MannequinAuthor
      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
    2. RamchandraApte
      added
      type-bugAn unexpected behavior, bug, or error
      topic-IDLE
      on Dec 5, 2011

    3. loewis commented on Dec 5, 2011

      @loewis
      loewismannequin
      on Dec 5, 2011
      Mannequin

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

    4. RamchandraApte commented on Dec 6, 2011

      @RamchandraApte
      RamchandraAptemannequin
      on Dec 6, 2011
      MannequinAuthor

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

    5. terryjreedy commented on Dec 12, 2011

      @terryjreedy
      terryjreedy
      on Dec 12, 2011
      Member

      We should like the IDLE shell to give the same results as the standard shell. See bpo-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>
    6. terryjreedy
      added
      type-crashA hard crash of the interpreter, possibly with a core dump
      and removed
      type-bugAn unexpected behavior, bug, or error
      on Dec 12, 2011

    7. serwy commented on Dec 13, 2011

      @serwy
      serwymannequin
      on Dec 13, 2011
      Mannequin

      The crash can be prevented by using bpo-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.

    8. RamchandraApte
      changed the title [-]In IDLE, sys.stdout.write and sys.stderr can write any pickleable object[/-] [+]In IDLE, sys.stdout and sys.stderr can write any pickleable object[/+] on Dec 14, 2011

    9. loewis commented on Dec 14, 2011

      @loewis
      loewismannequin
      on Dec 14, 2011
      Mannequin

      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.

    10. loewis
      changed the title [-]In IDLE, sys.stdout and sys.stderr can write any pickleable object[/-] [+]In IDLE, sys.stdout.write and sys.stderr can write any pickleable object[/+] on Dec 14, 2011

    11. terryjreedy commented on Dec 14, 2011

      @terryjreedy
      terryjreedy
      on Dec 14, 2011
      Member

      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.

    12. loewis commented on Dec 14, 2011

      @loewis
      loewismannequin
      on Dec 14, 2011
      Mannequin

      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.

    13. RamchandraApte commented on Dec 15, 2011

      @RamchandraApte
      RamchandraAptemannequin
      on Dec 15, 2011
      MannequinAuthor

      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.

    14. 15 remaining items

    15. loewis
      closed this as completedon Jul 9, 2012

    16. serwy commented on Jul 9, 2012

      @serwy
      serwymannequin
      on Jul 9, 2012
      Mannequin

      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.

    17. loewis commented on Jul 9, 2012

      @loewis
      loewismannequin
      on Jul 9, 2012
      Mannequin

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

    18. terryjreedy commented on Jul 9, 2012

      @terryjreedy
      terryjreedy
      on Jul 9, 2012
      Member

      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)?

    19. loewis commented on Jul 9, 2012

      @loewis
      loewismannequin
      on Jul 9, 2012
      Mannequin

      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.

    20. python-dev commented on Jul 9, 2012

      @python-dev
      python-devmannequin
      on Jul 9, 2012
      Mannequin

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

    21. terryjreedy commented on Jul 9, 2012

      @terryjreedy
      terryjreedy
      on Jul 9, 2012
      Member

      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.

    22. serhiy-storchaka commented on Jul 10, 2012

      @serhiy-storchaka
      serhiy-storchaka
      on Jul 10, 2012
      Member
      •    sys.stdin = self.console = \_RPCFile(self.get_remote_proxy("stdin"))

      write to sys.stdin?

    23. serwy commented on Jul 10, 2012

      @serwy
      serwymannequin
      on Jul 10, 2012
      Mannequin

      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.

    24. serwy commented on Jul 10, 2012

      @serwy
      serwymannequin
      on Jul 10, 2012
      Mannequin

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

    25. serwy
      reopened this on Jul 10, 2012

    26. serhiy-storchaka commented on Jul 10, 2012

      @serhiy-storchaka
      serhiy-storchaka
      on Jul 10, 2012
      Member
      >>> sys.stdin.readable()
False
>>> sys.stdout.writable()
False

      I think the issue is far from a solution.

    27. loewis commented on Jul 10, 2012

      @loewis
      loewismannequin
      on Jul 10, 2012
      Mannequin

      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.

    28. loewis
      closed this as completedon Jul 10, 2012
    29. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      topic-IDLEtype-crashA hard crash of the interpreter, possibly with a core dump

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions