[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

Change by STINNER Victor :


--
Removed message: https://bugs.python.org/msg353517

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

Warnings options priority are badly documented. The latest major change was 
bpo-20361 when -b command line option changed to get the highest priority (-b > 
-W).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

> 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

--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[Batuhan]

Batuhan  added the comment:

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

--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33135] Define field prefixes for the various config structs

[Nick Coghlan]

New submission from Nick Coghlan :

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.

--
messages: 314398
nosy: eric.snow, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Define field prefixes for the various config structs
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com