Re: [Python-Dev] configparser 1.1 - one last bug fix needed
Antoine Pitrou wrote: On Tue, 14 Dec 2010 10:20:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) Or we can put it in the buggy module which receives all buggy code. The good thing about that idea is that maintenance of buggy.py will be so simple! -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano st...@pearwood.info wrote: The good thing about that idea is that maintenance of buggy.py will be so simple! It's self-describing, and needs no further documentation. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org A storm broke loose in my mind. --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
On Dec 14, 2010, at 3:38 AM, Fred Drake wrote: On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano st...@pearwood.info wrote: The good thing about that idea is that maintenance of buggy.py will be so simple! It's self-describing, and needs no further documentation. :-) And psychologically more effective than deprecation. Anyone writing import buggy probably feels like they have got some explaining to do :-) Raymond___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
On 14/12/2010 17:01, Raymond Hettinger wrote: On Dec 14, 2010, at 3:38 AM, Fred Drake wrote: On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Apranost...@pearwood.info wrote: The good thing about that idea is that maintenance of buggy.py will be so simple! It's self-describing, and needs no further documentation. :-) And psychologically more effective than deprecation. Anyone writing import buggy probably feels like they have got some explaining to do :-) They might be intro retro-robotics: http://www.anf.nildram.co.uk/beebcontrol/buggies/bbc_buggy/index.html (For those not in the UK, this was a very popular schools project kit on the back of the famous BBC micro initiative) TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] configparser 1.1 - one last bug fix needed
Hi there.
There's one last thing that needs to be done with configparser for 3.2.
Raymond, Fred, Michael and Georg already expressed their approval on that so
unless anybody finds a flaw in the idea expressed below, I'm going to make
the change for 3.2b2:
- the ConfigParser class will be removed
- the SafeConfigParser class will be renamed to ConfigParser
- 2to3 will rename SafeConfigParser classes to ConfigParser
- 2to3 will warn on the subtle behaviour change when ConfigParser classes
are found
What's the difference?
--
Both ConfigParser and SafeConfigParser implement interpolation, e.g. option
values can contain special tokens similar to those implemented by Python's
string formatting: %(example)s. These tokens are replaced during get()
operations by values from respective keys (either from the current section
or from the DEFAULT section).
SafeConfigParser was originally introduced to fix a couple of ConfigParser
problems:
- when a token didn't match the %(name)s syntax, it was simply treated as
a raw value. This caused configuration errors like %var or %(no_closing_s)
to be missed.
- if someone actually wanted to store arbitrary strings in values, including
Python formatting strings, there was no way to escape %(name)s in the
configuration. The programmer had to know in advance that some value may
hold %(name)s and only get() values from that option using
get('section', 'option', raw=True)
Then however, that option could not use interpolation anymore.
- set() originally allowed to store non-string values in the parser. This
was not meant to be a feature and caused trouble when the user tried to
save the configuration to a file or get the stored values back using typed
get() methods.
SafeConfigParser solves these problems by validating interpolation syntax
(only %(name)s or %% are allowed, the latter being an escaped percent sign)
and raising exceptions on syntax errors, and validating type on set()
operations so that no non-string values can be passed to the parser using
the API.
Why change that?
When ConfigParser was left alone, it remained the default choice for most
end users, including our own distutils and logging libs. This was a very
weak choice, and most current ConfigParser users are not aware of the
interpolation quirks. I had to close a couple of issues related to people
trying to store non-string values internally in the parser.
The current situation needlessly complicates the documentation. Explaining
all the above quirks to each new user who only wants to parse an INI file is
weak at best. Moreover, users trust Python to do the right thing by default
and according to their intuition. In this case, going for the default
configparser.ConfigParser class without consulting the documentation is
clearly a suboptimal choice.
One last argument is that SafeConfigParser is an awkward name. It implicates
the other parsers are somehow unsafe, or that this specific parser protects
users from something. This is generally considered a naming antipattern.
When?
-
You might ask whether this can be done for 3.2 (e.g. is that a feature or
a bugfix). In Raymond's words, the beta process should be used to flesh out
the APIs, test whether they work as expected and fix suboptimal decisions
before we hit the release candidate stage. He consideres this essentially
a bugfix and I agree.
You might ask why do that now and not for 3.3. We believe that 3.2 is the
last possible moment of introducing a change like that. The adoption rate is
currently still low and application authors porting projects from 2.x expect
incompatibilities. When they are non-issues, handled by 2to3, there's
nothing to be afraid of.
But isn't that... INCOMPATIBLE?!
Yes, it is. Thanks to the low py3k adoption rate now's the only moment where
there's marginal risk of introducing silent incompatibility (there are
hardly any py3k projects out there). Projects ported from Python 2.x will be
informed by 2to3 of the change. We believe that this will fix more bugs than
it introduces.
Support for bare % signs would be the single case where ConfigParser might
have appeared a more natural solution. In those cases we expect that users
will rather choose to turn off interpolation whatsoever.
Summary
---
If you have any strong, justified arguments against this bugfix, speak up.
Otherwise the change will be made on Thursday.
--
Interpolating regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
+1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
Wiadomość napisana przez Nick Coghlan w dniu 2010-12-14, o godz. 01:20: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) We may leave the LegacyInterpolation class if someone *really* needs to support that. That way RawConfigParser(interpolation=LegacyInterpolation()) is effectively the old ConfigParser. -- Nondeprecatorily yours, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
On Tue, 14 Dec 2010 10:20:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) Or we can put it in the buggy module which receives all buggy code. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
