Re: configparser - which one?
DL Neil writes: > After striking this problem, I was encouraged to take a look at JSON, > and thence YAML. Once there, as they say, didn't look back! > - multi-dimensional possibilities, cf .ini > - similarity/correspondence with Python data structures > - convenient PSL > - easily adopted by (power-)users, cf Python code Those are all true. Drawbacks for YAML as a configuration format: * Not implemented in Python standard library. * Not a single, unambiguous standard which all implementations support (this may be one reason for no Python standard library implementation). Despite those, yes I would very much prefer to use YAML as a configuration format. (ConfigParser INI format is acceptable. JSON is definitely not, because it has no simple way to put comments in the file.) -- \ “In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end.” —Mark | _o__)Pilgrim, 2006 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 27/03/19 2:44 AM, Grant Edwards wrote:
On 2019-03-26, Cameron Simpson wrote:
Like JSON, YAML etc are far far easier than XML for the reader.
If "far far easier than XML for the reader" is the bar, then we'll
have to keep "nailgun to the eyeballs" on the list...
That said, I agree with the rest of Cameron's post: for simpler stuff
.ini is darn hard to beat. If you need nesting/arrays, then I'd
probably pick YAML over JSON. Making simple changes to an
automatically-generated JSON file by hand is easy enough. But, I find
generating anything remotely complex by hand is far easier in YAML
than it is in JSON. As usual, YMMV.
In my users' case, choosing YAML was a decision made before the
(relatively) recent improvements to the .ini interface. (Thanks for that
news!)
From a programmer's PoV, the convenience of having whatever
config-file-rules handled within a library, so that your incoming data
is 'reduced' to a dict/list structure, cannot be understated.
From a user's PoV, (the few who should ever be allowed to come into
contact with such things) both .ini and YAML (and presumably) JSON are
readily understandable, in my experience (YMMV) - perhaps in this case
I've been 'blessed' with scientific/math/stats-types who are relatively
'power users' and used to planning their experiments/analyses!
As far as specs go, I can't say I've ever bothered to read those for
JSON, YAML, or even .ini. Have you? Read some article(s), started
'playing', achieved what was required, no fuss-no muss... The previous
post criticising same, lacks specifics, so can't learn from it. Earlier,
mention was made of multiple 'dimensions' which are (at least to me, and
those users) 'cleaner' in YAML/JSON/XML - however, heading 'too far' in
that direction invites 'trouble'. What does the Zen of Python say about
simplicity!
As with all tools, one really important criteria is the quality of
information-provided when things 'go wrong'. We've all been frustrated
because a 'missing comma/bracket/colon/...' "on line nnn" is not
supposed to be there at all - and we've had to comb 'backwards' through
the code to find where the missing punctuation should have been...
Given the relative ease with which both .ini and YAML can (now) be
utilised (both by 'them' and by 'us'), there are not sufficient
advantages/disadvantages to make it a 'big deal'. Other factors come
into play and assume greater import: the OP mentioned
user-preference/spec; whichever format this user's other systems
utilise; the ease (reduced cost) of reaching into one's 'bag of tricks'
for an already-coded ("re-usable") config-function...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
Thanks Cameron. Dave, March 26, 2019 12:39 AM, "Cameron Simpson" wrote: > On 25Mar2019 23:24, Dave wrote: > >> On 3/25/19 10:58 PM, DL Neil wrote: >>> On 26/03/19 1:10 PM, Dave wrote: >> >> I use Python3 3, and expected learning how to use configparser >>>would be >> no big deal. Well! >> Seems there is configparser, >>>stdconfigparser, and safeconfigparser, and >> multiple ways to set > the section and entries to the section. A little confusing. I >>>want > to future-proof may >> code, so what should I be using? >>> (with apologies for not answering the question directly) >>> >>> After striking this problem, I was encouraged to take a look at >>JSON, and >>> thence YAML. Once >>> there, as they say, didn't look back! >>> - multi-dimensional possibilities, cf .ini >>> - similarity/correspondence with Python data structures >>> - convenient PSL >>> - easily adopted by (power-)users, cf Python code > > [...] >>> >> >> Wish I could do that. Customer wants .ini. I would need to sell them >on an >> alternative. The issue >> is human readable - .ini is easier for >people to understand. > > And I agree with the customer, absent more info. Unless you need deeply > nested stuff, .ini is much > easier for humans to read. Not everything is a match for it (unless you start > playing games with > "[clause.subclause.subsubclause]" stuff, which I'd argue is a smell > indicating a format change > might be good). > > But for stuff which does fit nicely into .ini, it is FAR FAR easier on the > reader. Like JSON, YAML > etc are far far easier than XML for the reader. > > Lots of stuff, particularly simple configs, go well in .ini. > > All that opinion aside: just use the configparser.ConfigParser class. It is > what _used_ to be > "SafeConfigParser" in Python 2. > > Here endith the lesson. > > Cheers, > Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 2019-03-26, Cameron Simpson wrote: > Like JSON, YAML etc are far far easier than XML for the reader. If "far far easier than XML for the reader" is the bar, then we'll have to keep "nailgun to the eyeballs" on the list... That said, I agree with the rest of Cameron's post: for simpler stuff .ini is darn hard to beat. If you need nesting/arrays, then I'd probably pick YAML over JSON. Making simple changes to an automatically-generated JSON file by hand is easy enough. But, I find generating anything remotely complex by hand is far easier in YAML than it is in JSON. As usual, YMMV. -- Grant Edwards grant.b.edwardsYow! HUMAN REPLICAS are at inserted into VATS of gmail.comNUTRITIONAL YEAST ... -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 2019-03-26, DL Neil wrote: > On 26/03/19 1:10 PM, Dave wrote: >> I use Python3 3, and expected learning how to use configparser would be >> no big deal. Well! Seems there is configparser, stdconfigparser, and >> safeconfigparser, and multiple ways to set the section and entries to >> the section. A little confusing. I want to future-proof may code, so >> what should I be using? > > (with apologies for not answering the question directly) > > After striking this problem, I was encouraged to take a look at JSON, > and thence YAML. Once there, as they say, didn't look back! Friends don't let friends use YAML. Indeed, I have always assumed that YAML is a joke that got out of control, like the Flat Earth Society. It's like they chose a list of goals and then set themselves a challenge to design a solution that fails at meeting those goals in the most spectacular way possible. I mean, the original point of it was that it was a simpler replacement for XML but the YAML spec is larger than the XML spec... that can't happen by accident, right? -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 3/26/19 4:29 AM, Terry Reedy wrote:
On 3/25/2019 8:10 PM, Dave wrote:
I use Python3 3, and expected learning how to use configparser would
be no big deal. Well! Seems there is configparser, stdconfigparser, and
configparser is what IDLE uses. I would read the extra or deleted
features of the others and see if they apply to your client's project.
safeconfigparser, and multiple ways to set the section and entries to
the section. A little confusing. I want to future-proof may code, so
what should I be using?
As for setting the sections and entries, the following both work.
from configparser import ConfigParser # Python 3 syntax
parser = ConfigParser()
parser['DEFAULT'] = {'Language': 'English',
'Units': 'English',
'UseDefaults': 'True',
'NumberRidesDisplay': '30',
'Pi': '3.14'}
The dict interface is newer but I doubt that the older one will go away.
(IDLE uses it because it predates the dict interface. Since this code
is pretty static, I do not currently see a payoff for conversion.)
parser.add_section('Default')
parser.set('default', 'language', 'english')
parser.set('default', 'units_measure', 'english')
parser.set('default', 'background_color', 'white')
parser.set('default', 'useDefaults', 'true')
parser.set('default', 'numToDisp', '12')
parser.set('default', 'pi', '3.14')
The advantage of the former is that it will handle 'DEFAULT', while
the last one won't. I like the former, but not sure if it is the future.
We do not remove things and break backwards compatibility lightly.
Thanks everyone. So, I'll use configparser, but I do like the
dictionary API as it makes the code a little easier as I can pass as
arguments a section name and a dictionary with the contents to a
function to write the complete section.
Dave,
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 3/25/2019 8:10 PM, Dave wrote:
I use Python3 3, and expected learning how to use configparser would be
no big deal. Well! Seems there is configparser, stdconfigparser, and
configparser is what IDLE uses. I would read the extra or deleted
features of the others and see if they apply to your client's project.
safeconfigparser, and multiple ways to set the section and entries to
the section. A little confusing. I want to future-proof may code, so
what should I be using?
As for setting the sections and entries, the following both work.
from configparser import ConfigParser # Python 3 syntax
parser = ConfigParser()
parser['DEFAULT'] = {'Language': 'English',
'Units': 'English',
'UseDefaults': 'True',
'NumberRidesDisplay': '30',
'Pi': '3.14'}
The dict interface is newer but I doubt that the older one will go away.
(IDLE uses it because it predates the dict interface. Since this code
is pretty static, I do not currently see a payoff for conversion.)
parser.add_section('Default')
parser.set('default', 'language', 'english')
parser.set('default', 'units_measure', 'english')
parser.set('default', 'background_color', 'white')
parser.set('default', 'useDefaults', 'true')
parser.set('default', 'numToDisp', '12')
parser.set('default', 'pi', '3.14')
The advantage of the former is that it will handle 'DEFAULT', while the
last one won't. I like the former, but not sure if it is the future.
We do not remove things and break backwards compatibility lightly.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 25Mar2019 23:24, Dave wrote: On 3/25/19 10:58 PM, DL Neil wrote: On 26/03/19 1:10 PM, Dave wrote: I use Python3 3, and expected learning how to use configparser would be no big deal. Well! Seems there is configparser, stdconfigparser, and safeconfigparser, and multiple ways to set the section and entries to the section. A little confusing. I want to future-proof may code, so what should I be using? (with apologies for not answering the question directly) After striking this problem, I was encouraged to take a look at JSON, and thence YAML. Once there, as they say, didn't look back! - multi-dimensional possibilities, cf .ini - similarity/correspondence with Python data structures - convenient PSL - easily adopted by (power-)users, cf Python code [...] Wish I could do that. Customer wants .ini. I would need to sell them on an alternative. The issue is human readable - .ini is easier for people to understand. And I agree with the customer, absent more info. Unless you need deeply nested stuff, .ini is much easier for humans to read. Not everything is a match for it (unless you start playing games with "[clause.subclause.subsubclause]" stuff, which I'd argue is a smell indicating a format change might be good). But for stuff which does fit nicely into .ini, it is FAR FAR easier on the reader. Like JSON, YAML etc are far far easier than XML for the reader. Lots of stuff, particularly simple configs, go well in .ini. All that opinion aside: just use the configparser.ConfigParser class. It is what _used_ to be "SafeConfigParser" in Python 2. Here endith the lesson. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
On 3/25/19 10:58 PM, DL Neil wrote: Dave, On 26/03/19 1:10 PM, Dave wrote: I use Python3 3, and expected learning how to use configparser would be no big deal. Well! Seems there is configparser, stdconfigparser, and safeconfigparser, and multiple ways to set the section and entries to the section. A little confusing. I want to future-proof may code, so what should I be using? (with apologies for not answering the question directly) After striking this problem, I was encouraged to take a look at JSON, and thence YAML. Once there, as they say, didn't look back! - multi-dimensional possibilities, cf .ini - similarity/correspondence with Python data structures - convenient PSL - easily adopted by (power-)users, cf Python code WebRefs: - similar Q: https://stackoverflow.com/questions/5055042/whats-the-best-practice-using-a-settings-file-in-python - article: https://martin-thoma.com/configuration-files-in-python/ - similar discussion: https://stackoverflow.com/questions/3085029/pros-and-cons-for-different-configuration-formats Wish I could do that. Customer wants .ini. I would need to sell them on an alternative. The issue is human readable - .ini is easier for people to understand. Dave, -- https://mail.python.org/mailman/listinfo/python-list
Re: configparser - which one?
Dave, On 26/03/19 1:10 PM, Dave wrote: I use Python3 3, and expected learning how to use configparser would be no big deal. Well! Seems there is configparser, stdconfigparser, and safeconfigparser, and multiple ways to set the section and entries to the section. A little confusing. I want to future-proof may code, so what should I be using? (with apologies for not answering the question directly) After striking this problem, I was encouraged to take a look at JSON, and thence YAML. Once there, as they say, didn't look back! - multi-dimensional possibilities, cf .ini - similarity/correspondence with Python data structures - convenient PSL - easily adopted by (power-)users, cf Python code WebRefs: - similar Q: https://stackoverflow.com/questions/5055042/whats-the-best-practice-using-a-settings-file-in-python - article: https://martin-thoma.com/configuration-files-in-python/ - similar discussion: https://stackoverflow.com/questions/3085029/pros-and-cons-for-different-configuration-formats -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
configparser - which one?
I use Python3 3, and expected learning how to use configparser would be
no big deal. Well! Seems there is configparser, stdconfigparser, and
safeconfigparser, and multiple ways to set the section and entries to
the section. A little confusing. I want to future-proof may code, so
what should I be using?
As for setting the sections and entries, the following both work.
from configparser import ConfigParser # Python 3 syntax
parser = ConfigParser()
parser['DEFAULT'] = {'Language': 'English',
'Units': 'English',
'UseDefaults': 'True',
'NumberRidesDisplay': '30',
'Pi': '3.14'}
parser.add_section('Default')
parser.set('default', 'language', 'english')
parser.set('default', 'units_measure', 'english')
parser.set('default', 'background_color', 'white')
parser.set('default', 'useDefaults', 'true')
parser.set('default', 'numToDisp', '12')
parser.set('default', 'pi', '3.14')
The advantage of the former is that it will handle 'DEFAULT', while the
last one won't. I like the former, but not sure if it is the future.
Thanks,
Dave
--
https://mail.python.org/mailman/listinfo/python-list
