This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: pprint() gives exception when ran from pythonw
Type: Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.11
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: henriquesdj0, iritkatriel, luizeldorado, ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, veky, zach.ware
Priority: normal Keywords: patch

Created on 2020-08-14 00:10 by luizeldorado, last changed 2022-04-11 14:59 by admin. This issue is now closed.

File name Uploaded Description Edit
pprint_error_showcase.pyw luizeldorado, 2020-08-14 00:10 Showcase of the problem
Pull Requests
URL Status Linked Edit
PR 26810 merged iritkatriel, 2021-06-20 14:00
Messages (10)
msg375358 - (view) Author: Luiz (luizeldorado) Date: 2020-08-14 00:10
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/, 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.
msg375382 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-08-14 08:49
Thanks for the report.  Just to be clear, this is running on Windows?  And, if so, which version?
msg375401 - (view) Author: Luiz (luizeldorado) Date: 2020-08-14 13:22
I'm on Windows 7.
msg375413 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-08-14 15:19
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.
msg375422 - (view) Author: Luiz (luizeldorado) Date: 2020-08-14 18:25
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.
msg375435 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-08-14 22:15
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
does not mention the pyw version.

But this is not really a windowed mode issue.  In a Windows console:
>>> print('hello')
>>> import sys; sys.stdout = None
>>> print('hello')
>>> sys.stdout = sys.__stdout__
>>> print('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.
msg375503 - (view) Author: Henrique Gj (henriquesdj0) Date: 2020-08-16 05:04
> Debug prints should not crash a program.

> 'Not a bug'

msg375534 - (view) Author: Vedran Čačić (veky) * Date: 2020-08-17 08:19
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.
msg375565 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-08-17 19:47
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"?
msg397781 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-07-19 09:19
New changeset aab1899c9d79083c1ff31d974ed8b562d3ca3b5d by Irit Katriel in branch 'main':
bpo-41546: make pprint (like print) not write to stdout when it is None (GH-26810)
Date User Action Args
2022-04-11 14:59:34adminsetgithub: 85718
2021-07-19 09:20:09iritkatrielsetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2021-07-19 09:19:06iritkatrielsetmessages: + msg397781
2021-06-20 14:02:01iritkatrielsetversions: + Python 3.11, - Python 3.10
2021-06-20 14:00:21iritkatrielsetkeywords: + patch
nosy: + iritkatriel

pull_requests: + pull_request25392
stage: patch review
2020-08-17 19:47:56steve.dowersetmessages: + msg375565
versions: + Python 3.10, - Python 3.8
2020-08-17 08:19:48vekysetnosy: + veky
messages: + msg375534
2020-08-16 05:04:48henriquesdj0setnosy: + henriquesdj0
messages: + msg375503
2020-08-14 22:15:33terry.reedysettype: behavior ->

messages: + msg375435
nosy: + terry.reedy
2020-08-14 18:25:01luizeldoradosetmessages: + msg375422
2020-08-14 15:19:08steve.dowersetmessages: + msg375413
2020-08-14 13:22:41luizeldoradosetmessages: + msg375401
2020-08-14 08:49:00ned.deilysetnosy: + ned.deily, paul.moore, tim.golden, zach.ware, steve.dower
messages: + msg375382
components: + Windows
2020-08-14 00:10:04luizeldoradocreate