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']

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.

+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 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

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

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

Navigation Menu

Repository navigation

Define field prefixes for the various config structs #77316

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Define field prefixes for the various config structs #77316

Description

Activity

ncoghlan commented on Mar 25, 2018

isidentical commented on May 15, 2019

vstinner commented on May 15, 2019

vstinner commented on May 27, 2019

vstinner commented on Sep 30, 2019

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions