Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pprint() gives exception when ran from pythonw #85718

Closed
luizeldorado mannequin opened this issue Aug 14, 2020 · 10 comments
Closed

pprint() gives exception when ran from pythonw #85718

luizeldorado mannequin opened this issue Aug 14, 2020 · 10 comments
Labels
3.11 only security fixes OS-windows stdlib Python modules in the Lib dir

Comments

@luizeldorado
Copy link
Mannequin

luizeldorado mannequin commented Aug 14, 2020

BPO 41546
Nosy @terryjreedy, @pfmoore, @tjguk, @ned-deily, @zware, @zooba, @vedgar, @iritkatriel, @luizeldorado
PRs
  • bpo-41546: make pprint (like print) not write to stdout when it is None #26810
  • Files
  • pprint_error_showcase.pyw: Showcase of the problem
  • 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 2021-07-19.09:20:09.349>
    created_at = <Date 2020-08-14.00:10:04.341>
    labels = ['library', 'OS-windows', '3.11']
    title = 'pprint() gives exception when ran from pythonw'
    updated_at = <Date 2021-07-19.09:20:09.349>
    user = 'https://github.com/luizeldorado'

    bugs.python.org fields:

    activity = <Date 2021-07-19.09:20:09.349>
    actor = 'iritkatriel'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-07-19.09:20:09.349>
    closer = 'iritkatriel'
    components = ['Library (Lib)', 'Windows']
    creation = <Date 2020-08-14.00:10:04.341>
    creator = 'luizeldorado'
    dependencies = []
    files = ['49388']
    hgrepos = []
    issue_num = 41546
    keywords = ['patch']
    message_count = 10.0
    messages = ['375358', '375382', '375401', '375413', '375422', '375435', '375503', '375534', '375565', '397781']
    nosy_count = 10.0
    nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'ned.deily', 'zach.ware', 'steve.dower', 'veky', 'iritkatriel', 'luizeldorado', 'henriquesdj0']
    pr_nums = ['26810']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue41546'
    versions = ['Python 3.11']

    @luizeldorado
    Copy link
    Mannequin Author

    luizeldorado mannequin commented Aug 14, 2020

    If you use the pprint function when running on windowed mode (either by using the .pyw extension or running the file with pythonw) a "AttributeError" exception occurs, saying that "'NoneType' object has no attribute 'write'".

    Looking at the source code (Lib/pprint.py), it happens because in this mode sys.stdout is set to None, therefore it has no write attribute.

    I think intended behavior is to simply ignore any console output when in this mode, since many programs have loads of print statements for debugging with a console window; it shouldn't crash because of a extension change.

    There's two solutions I can think of. One is to check if sys.stdout is None, not printing anything in case it is. Another is, when in windowed mode, setting sys.stdout to some dummy null file. This has the advantage of automatically fixing this in other parts of Python where this error might also occur.

    This error is particularly hard to find, since in windowed mode there's no console to show the exception - it simply closes. In the attached file, where I showcase the error, I have to log to a file to see the problem.

    I'm not sure how can this be unnoticed for so much time, it can't possibly be intended, or maybe it is and it's print() that actually has a problem, lol.

    @luizeldorado luizeldorado mannequin added type-bug An unexpected behavior, bug, or error 3.8 only security fixes stdlib Python modules in the Lib dir labels Aug 14, 2020
    @ned-deily
    Copy link
    Member

    Thanks for the report. Just to be clear, this is running on Windows? And, if so, which version?

    @luizeldorado
    Copy link
    Mannequin Author

    luizeldorado mannequin commented Aug 14, 2020

    I'm on Windows 7.

    @zooba
    Copy link
    Member

    zooba commented Aug 14, 2020

    This is normal, if obscure, behaviour. Pythonw starts without a console, and so stdout is not connected to anything. As a result, you can't print (or pprint).

    You'll need to set sys.stdout to something or provide a file if you want to print output.

    If someone wants to contribute a specialised sys.stdout implementation that can raise a more helpful error message in this case, that would be helpful. But as it's a breaking change it would only go into 3.10.

    @luizeldorado
    Copy link
    Mannequin Author

    luizeldorado mannequin commented Aug 14, 2020

    If this is normal behavior, then why does print() not produce any error? Shouldn't it say that it can't print because there's no stdout? That's not very consistent, both functions have almost the same name yet produce very different results.

    @terryjreedy
    Copy link
    Member

    If you run in windowed mode, you are expected to either not use sys.stdout or to provide a working sys.stdout object. I am not sure if that is explicitly documented as I cannot find python.exe and pythonw.exe or .py or .pyw in the index and
    https://docs.python.org/3/using/windows.html#python-launcher-for-windows
    does not mention the pyw version.

    But this is not really a windowed mode issue.  In a Windows console:
    >>> print('hello')
    hello
    >>> import sys; sys.stdout = None
    >>> print('hello')
    >>> sys.stdout = sys.__stdout__
    >>> print('hello')
    hello

    print and pprint act differently because pprint uses stream.write without try/except. Check the doc or code. So pprint users must run it with a stream with that method. Otherwise, failure is to be expected.

    If you try to print to None, print defaults to sys.stdout. The doc does not define what happens when the latter is None. On CPython, print passes. But maybe this is left undefined intentionally. It must either check that file is not None or catch the AttributeError.

    Shouldn't it say that it can't print because there's no stdout?
    How could it if there is no channel to speak? I guess Guido decided to silently pass rather than silently exit. Debug prints should not crash a program.

    So closing as 'Not a bug' would be one appropriate resolution for this issue.

    @terryjreedy terryjreedy removed type-bug An unexpected behavior, bug, or error labels Aug 14, 2020
    @henriquesdj0
    Copy link
    Mannequin

    henriquesdj0 mannequin commented Aug 16, 2020

    Debug prints should not crash a program.

    'Not a bug'

    wait

    @vedgar
    Copy link
    Mannequin

    vedgar mannequin commented Aug 17, 2020

    The big part of the justification for making print a function in Py3 is that it can be painlessly replaced with other functions, such as (example given by BDFL) pprint.pprint. I think we should do what we can to make the replacement as painless as possible.

    @zooba
    Copy link
    Member

    zooba commented Aug 17, 2020

    I'm inclined to agree that it should pass silently in this case, as if it were printing with print() rather than .write().

    What better meaning is there for sys.stdout == None than "no output"?

    @zooba zooba added 3.10 only security fixes and removed 3.8 only security fixes labels Aug 17, 2020
    @iritkatriel iritkatriel added 3.11 only security fixes and removed 3.10 only security fixes labels Jun 20, 2021
    @iritkatriel
    Copy link
    Member

    New changeset aab1899 by Irit Katriel in branch 'main':
    bpo-41546: make pprint (like print) not write to stdout when it is None (GH-26810)
    aab1899

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.11 only security fixes OS-windows stdlib Python modules in the Lib dir
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants