Define field prefixes for the various config structs

[ncoghlan]

BPO	33135
Nosy	@ncoghlan, @vstinner, @ericsnowcurrently, @nanjekyejoannah, @isidentical

^{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:

assignee = None
closed_at = <Date 2019-05-27.15:31:08.406>
created_at = <Date 2018-03-25.06:10:23.198>
labels = ['3.8', 'type-feature', '3.7']
title = 'Define field prefixes for the various config structs'
updated_at = <Date 2019-09-30.00:30:42.150>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2019-09-30.00:30:42.150>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-05-27.15:31:08.406>
closer = 'vstinner'
components = []
creation = <Date 2018-03-25.06:10:23.198>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 33135
keywords = []
message_count = 5.0
messages = ['314398', '342562', '342574', '343646', '353519']
nosy_count = 5.0
nosy_names = ['ncoghlan', 'vstinner', 'eric.snow', 'nanjekyejoannah', 'BTaskaya']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue33135'
versions = ['Python 3.7', 'Python 3.8']

[ncoghlan]

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:

• 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_" prefix

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.

[isidentical]

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

[vstinner]

In the master branch, the C function config_read_cmdline() uses:

• cmdline_warnoptions: -W command line arguments
• env_warnoptions: PYTHONWARNINGS environment variable

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:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules

[vstinner]

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 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:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules

[vstinner]

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