Repository navigation
Define field prefixes for the various config structs #77316
Description
| 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']
Activity
ncoghlan commentedon Mar 25, 2018
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.
isidentical commentedon May 15, 2019
+1 from me. But i dont understand why this issue triaged as "needs patch". Isn't it should be discussed first?
vstinner commentedon May 15, 2019
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:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules
vstinner commentedon May 27, 2019
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 commentedon Sep 30, 2019
(Oops, I posted a comment to the wrong issue, it was a comment for bpo-38317.)