While working onhttps://bugs.python.org/issue33042, I found it hard to keep track of which kind of config struct a particular piece of code was referencing.As a particularly relevant example, we currently have 3 different "warnoptions" fields: the private-to-main one for reading the command line settings, the "wchar_t *" list in the core config, and the "PyObject *" list object in the main interpreter config (which is also the one aliased as sys.warnoptions).What do you think of adopting a convention where:* the command line fields all gain a "cmd_" prefix* the core config fields all gain a "c_" prefix* the interpreter config fields all gain a "py_" prefixWe'd then have "cmd_warnoptions", "c_warnoptions", and "py_warnoptions" as the field names, and it would be more self-evident which layer we were working at in any particular piece of code.

+1 from me. But i dont understand why this issue triaged as "needs patch". Isn't it should be discussed first?

In the master branch, the C function config_read_cmdline() uses:* cmdline_warnoptions: -W command line arguments* env_warnoptions: PYTHONWARNINGS environment variableThe config_init_warnoptions() uses these 2 list and combine it with other options, dev_mode and bytes_warnings.The warnings options are now specified in myPEP 587:https://www.python.org/dev/peps/pep-0587/#priority-and-rules

> As a particularly relevant example, we currently have 3 different "warnoptions" fields: the private-to-main one for reading the command line settings, the "wchar_t *" list in the core config, and the "PyObject *" list object in the main interpreter config (which is also the one aliased as sys.warnoptions).This issue has been fixed inbpo-36763 with the implementation of thePEP 587. PyConfig.warnoptions is now an unified list of warnings options. Moreover, the priority of warnings options is now defined at:https://www.python.org/dev/peps/pep-0587/#priority-and-rules

(Oops, I posted a comment to the wrong issue, it was a comment forbpo-38317.)