fix: prevent crash when calling pybind11::print in a subsystem:windows build

[oxine]

fix: prevent crash when calling pybind11::print in a subsystem:windows build

Description

Calling pybind11::print() crash in MSVC v19.44 with /subsystem:windows given.

In line: file = module_::import("sys").attr("stdout"); the file will be none in a windows application build. won't be catched since there's no exception, and crashed in later access.

Add check before accessing file to prevent crash.

[rwgk]

I asked Cursor Opus 4.6 1M Thinking the questions below. I think we need at least (a) and (b) in the "Bottom line" response. However, this seems actually best to me: RuntimeError("sys.stdout missing or lost")

I.e. that amounts to steering users towards:

• just remove or guard your print, or
• reset sys.stdout to a /dev/null-equivalent

Two easy alternatives that don't run the danger of silent data loss.

---

What is a "subsystem:windows" build?

It refers to the MSVC linker flag /SUBSYSTEM:WINDOWS. This tells the linker to produce a Windows GUI application (e.g. a native Win32 or WPF app) rather than a console application (/SUBSYSTEM:CONSOLE). The crucial difference: a SUBSYSTEM:WINDOWS app has no console allocated by default — there is no terminal window. As a result, sys.stdout is None in an embedded Python interpreter running inside such an app, because there's simply no console to attach it to.

The crash path is:

1. pybind11::print() is called
2. It fetches sys.stdout at line 3541 — this succeeds (no exception), but the value is None
3. The existing try/catch doesn't help because no exception was thrown
4. It falls through to file.attr("write"), which crashes because None has no write attribute

Is it legit to silently drop the print?

It's defensible, but worth scrutinizing. A few angles:

In favor

• CPython does the same thing. In CPython's builtin_print_impl, if sys.stdout is None and no explicit file= was given, it silently returns None — no output, no error. So this PR is matching Python's own semantics.
• There's already precedent in this very function. The try/catch block (lines 3540–3548) already silently swallows the print if sys can't be imported during interpreter shutdown. The rationale comment says "give up rather than crashing."
• Crashing is strictly worse. If there's no stdout, there's genuinely nowhere to write.

Against / things to consider

• Silent data loss is a code smell. A developer embedding Python in a GUI app might spend a long time debugging why their pybind11::print() calls produce no output and no error. At minimum, a comment explaining why the silent return is intentional would help future readers.
• Alternatives exist. The code could try sys.stderr as a fallback (which might be redirected even in a GUI app), or use OutputDebugString on Windows so the output shows up in a debugger, or raise a Python-level RuntimeError("lost sys.stdout").
• The file= keyword path isn't guarded. If the user explicitly passes file=None (lines 3537–3538), the is_none() check will also silently drop that. One could argue that's a distinct case — an explicit file=None from the user is probably a bug and deserves an error, whereas an implicit sys.stdout being None due to the environment is a "not my fault" situation.

Bottom line

It's a legitimate fix for the crash, and it matches CPython behavior, so it's not wrong. But it's the minimum viable fix. A stronger version might (a) add a brief comment explaining the Windows subsystem scenario, and (b) consider distinguishing between "user explicitly passed file=None" vs. "sys.stdout happens to be None." The silent drop for the latter is fine; for the former, an error would be more helpful.

[henryiii]

I'd be okay with throwing an error only if a user passes file explicitly, but I think following CPython here and not doing anything if you can't print is better:

a) It's consistent with CPython
b) You might not "own" the code doing the print, so if it throws an error, you might not be able to fix it - throwing an error is still a "crash", just a catchable one
c) Print is very often used as a debug statement, you don't want a debug statement crashing (or throwing an error) just because you can't print.
d) Where do you plan to print the error to if you can't print?