This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients eric.snow, ncoghlan, vstinner
Date 2018-03-25.06:10:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521958223.34.0.467229070634.issue33135@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-03-25 06:10:23ncoghlansetrecipients: + ncoghlan, vstinner, eric.snow
2018-03-25 06:10:23ncoghlansetmessageid: <1521958223.34.0.467229070634.issue33135@psf.upfronthosting.co.za>
2018-03-25 06:10:23ncoghlanlinkissue33135 messages
2018-03-25 06:10:22ncoghlancreate