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
Define field prefixes for the various config structs #77316
Comments
While working on https://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:
We'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:
The 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 my PEP-587: |
This issue has been fixed in bpo-36763 with the implementation of the PEP-587. PyConfig.warnoptions is now an unified list of warnings options. Moreover, the priority of warnings options is now defined at: |
(Oops, I posted a comment to the wrong issue, it was a comment for bpo-38317.) |
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: