* Florian Bruhin m...@the-compiler.org [2014-04-25 16:22:06 +0200]:
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
I've now submitted an issue here: http://bugs.python.org/issue21498
Florian
--
() ascii ribbon campaign - stop html mail
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano st...@pearwood.info wrote:
I think that a line beginning with #spam is ambiguous, it isn't clear
if it is intended as a comment spam or a key starting with #, so by
the Zen, configparser should refuse to guess.
Seriously?
Perhaps the second
On Sat, Apr 26, 2014 at 01:59:27AM -0400, Fred Drake wrote:
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano st...@pearwood.info wrote:
I think that a line beginning with #spam is ambiguous, it isn't clear
if it is intended as a comment spam or a key starting with #, so by
the Zen,
On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano st...@pearwood.info wrote:
But the entry in question wasn't a line, it was a key=value pair in a
dict. Here's that line again:
cp.read_dict({'DEFAULT': {';foo': 'bar'}})
or it could have been:
cp['DEFAULT'][';foo'] = 'bar'
Either way, if
On Apr 25, 2014, at 11:47 AM, Terry Reedy tjre...@udel.edu wrote:
So I wonder whether the thought-to-be-buggy behavior is
actually buggy with respect to *all* the supported styles or just some of them.
I can't how being able to write a file that isn't read back with the
same meaning could be
Hi,
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
Consider this example:
cp = configparser.ConfigParser()
cp.read_dict({'DEFAULT': {';foo': 'bar'}})
cp.write(sys.stdout)
[DEFAULT]
;foo = bar
Now when reading this
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin m...@the-compiler.org wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
I'd expect writing something and then reading it back via the
On 4/25/2014 12:46 PM, Fred Drake wrote:
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin m...@the-compiler.org wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
I'd expect writing
On 04/25/2014 09:46 AM, Fred Drake wrote:
At this point, it would be a backward-incompatible change, so it's
unlikely such a change could be allowed to affect existing code.
All bug-fixes are backwards-incompatible, yet we fix them anyway. ;)
It seems to me the real question is do we fix it
On 4/25/2014 1:41 PM, Ethan Furman wrote:
On 04/25/2014 09:46 AM, Fred Drake wrote:
At this point, it would be a backward-incompatible change, so it's
unlikely such a change could be allowed to affect existing code.
All bug-fixes are backwards-incompatible, yet we fix them anyway. ;)
It
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy tjre...@udel.edu wrote:
I leave it to someone to carefully read the doc, but a brief glance
indicates There are nearly as many INI format variants as there are
applications using it. configparser goes a long way to provide support for
the largest
On 04/25/2014 11:54 AM, Fred Drake wrote:
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy tjre...@udel.edu wrote:
I leave it to someone to carefully read the doc, but a brief glance
indicates There are nearly as many INI format variants as there are
applications using it. configparser goes a long
On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman et...@stoneleaf.us wrote:
Perhaps an enhancement request then: a way to provide a regex that keys
must match, with an exception raised when a key doesn't. That way the
safety belt could be used when desired.
You can subclass the parser class
On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote:
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin m...@the-compiler.org
wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
14 matches
Mail list logo
