Hum, I think that the "Porting to Python 3.12" is a better section for these changes. The "syslog" section is more for new features.

Why can syslog.syslog only be used when the main interpreter has called syslog.openlog? That's a restriction that is not present in the underlying library.

@ronaldoussoren cc @ericsnowcurrently
This might be the discussion part for this change, from the view of managing for open/close state, subinterpreter should not intervene in changing the state of open/close. And this is why syslog.openlog and syslog.closelog are not available to the subinterpreter side. so if the subinterpreter can call syslog.syslog() without involving the main interpreter, it means that subinterpreter intervenes in the state of open/close so I think that it should be prevented.

Calling openlog (and closelog) is optional in syslog(3) with sensible defaults. There is no need to call openlog at all unless a program wants to change some of the default settings, and that could be done outside of the Python world.

For a use-case like embedding Python in a web server (like mod_python it is more likely that the embedding program does the syslog setup than that this is done in Python code.

Calling openlog (and closelog) is optional in syslog(3) with sensible defaults. There is no need to call openlog at all unless a program wants to change some of the default settings, and that could be done outside of the Python world.

In summary for your suggestion might be:

• syslog.syslog(): Allow for both the main interpreter and subinterpreters at any condition.
• syslog.openlog()/closelog(): Allow only for the main interpreter

But if the subinterpreter calls syslog.syslog() after the main interpreter calls the syslog.closelog(), the subinterpreter will neutralize what the main interpreter did. Who will close the syslog.syslog() that is opened by subinterpreter?

cc @ericsnowcurrently

There are two factors here:

1. most process-global resources should be managed by the app
2. we are storing a str object in a static variable (S_ident_o), which is tricky when multiple interpreters are involved

Regarding the first one, this is perhaps something that we need not be so strict about. In Python, "app" means the __main__ module, running in the main interpreter (starting in the main thread). This implies that the global resources modifed via syslog.openlog() and syslog.closelog() should only be managed in the main interpreter. This would be similar to how signal handlers are supported only in the main thread of the main interpreter. However, this could be an overly strict interpretation for syslog. It makes sense to me, but "consenting adults", etc.

Regarding the second factor, we have been (and still are) working hard to get interpreters isolated from one another, especially to avoid problems that arise when they step on each others' toes. [1] (Isolation also provides new implementation opportunities.) For example, an object created in one interpreter should never be modified (even just the refcount) by another interpreter. [2] In the case of syslog, the object in the static variable (set in syslog.openlog()) should be managed only by the interpreter that owns it. Here are ways to enforce this:

• the interpreter that calls openlog() should be the only one allowed to call closelog() (simplest way is to restrict to the main interpreter)
• if another interpreter calls closelog(), then it would call Py_AddPendingCall() to have the owning interpreter decref the string

Obviously we went with the simplest form of the first one.

On top of the existing isolation concerns, there are additional ones that become more complicated under a per-interpreter GIL due to thread-safety. These are a non-issue if we restrict to a per-interpreter GIL.

[1] Such problems would be amplified by a per-interpreter GIL (see PEP 684, which has not been accepted yet), but they still exist even now.
[2] Except for a small set of objects managed by the process-global runtime.

Regardless, if the concern is backward compatibility, we can easily apply the restriction only if the subinterpreter was created via Py_NewInterpreter() (or, under a per-interpreter GIL, is otherwise sharing the GIL with the main interpreter).

Calling openlog (and closelog) is optional in syslog(3) with sensible defaults. There is no need to call openlog at all unless a program wants to change some of the default settings, and that could be done outside of the Python world.

For a use-case like embedding Python in a web server (like mod_python it is more likely that the embedding program does the syslog setup than that this is done in Python code.

FWIW, both concerns are valid, but pre-date this PR.