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
Comments
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. |
Thanks for the report. Just to be clear, this is running on Windows? And, if so, which version? |
I'm on Windows 7. |
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. |
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. |
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 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.
So closing as 'Not a bug' would be one appropriate resolution for this issue. |
wait |
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. |
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"? |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: