Fwd: Re: Comparing Dictionaries
From: Steven D'Aprano [EMAIL PROTECTED]
Newsgroups: comp.lang.python
Subject: Re: Comparing Dictionaries
Date: Sat, 28 Jul 2007 10:21:14 +1000
To: python-list@python.org
On Fri, 27 Jul 2007 14:11:02 -0500, Kenneth Love wrote:
The published recipe (based on ConfigParser) did not handle my INI
files. I have periods in both the section names and the key names.
The INI files contents were developed according to an internally
defined process that other non-Python programs rely on. The published
recipe *did not work* with this scenario.
I think you have made a mistake. ConfigParser as published certainly DOES
accept periods in section and option names. It just *works*.
The recipe I'm using is based upon ConfigParser and creates a dictionary
that is based on the contents of the INI file. The dictionary's key is
based on the section name and the key name from the INI file. The two
are concatenated with a separator.
In the original recipe, the separator is a period. To use your example
(deleted as an attempt at brevity), the dictionary would be:
{ SECTION.FRED.option.wilma : 45 }
As originally written, the section name is now SECTION when you write
the INI file back out. The key is FRED.option.wilma.
Here is the original recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65334
My version replaces the period with a dollar sign giving:
{ SECTION.FRED$option.wilma : 45 }
I also removed the import string and put both the load() and save()
functions in a file with proper comments and the Python equivalent of
Javadoc comments.
Even if the existing ConfigParser doesn't do what you want, the right way
to fix the problem is not to recreate the entire module from scratch, but
to subclass it:
[snip]
In no way did I rewrite ConfigParser. I have a real job with time
pressures and I'm not so arrogant as to think I could whip something
up in an hour that would be anywhere close to correct.
I see that I wasn't as clear as I thought I was in my original post
as you are second person to think I was developing my own INI solution.
All I wanted to know was How do I compare two dictionaries to see if
they are equal?. It turns out that this functionality is built-in
and it is my own stupid fault that my unit test was failing (modifying
working code and writing a unit test at the same time is a recipe for
failure).
Oh well. Next time I'll spend two hours trying to figure it out instead
of one before I post. :-\
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kenneth Love | Oklahoma Tax Commission
DP Programmer/Analyst | Information Technology
(405) 522 - 5864 | http://www.tax.ok.gov/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Comparing Dictionaries
On Mon, 30 Jul 2007 14:06:29 -0500, Kenneth Love wrote:
From: Steven D'Aprano [EMAIL PROTECTED]
Newsgroups: comp.lang.python
Subject: Re: Comparing Dictionaries
Date: Sat, 28 Jul 2007 10:21:14 +1000
To: python-list@python.org
On Fri, 27 Jul 2007 14:11:02 -0500, Kenneth Love wrote:
The published recipe (based on ConfigParser) did not handle my INI
files. I have periods in both the section names and the key names.
The INI files contents were developed according to an internally
defined process that other non-Python programs rely on. The published
recipe *did not work* with this scenario.
I think you have made a mistake. ConfigParser as published certainly DOES
accept periods in section and option names. It just *works*.
The recipe I'm using is based upon ConfigParser and creates a dictionary
that is based on the contents of the INI file. The dictionary's key is
based on the section name and the key name from the INI file. The two
are concatenated with a separator.
In the original recipe, the separator is a period. To use your example
(deleted as an attempt at brevity), the dictionary would be:
{ SECTION.FRED.option.wilma : 45 }
Well, that's just broken.
Flat is better than nested is only true when things are actually better
flat rather than nested. The right way to build a dictionary from an INI
file is with nested dictionaries:
{SECTION1: {option1: 20, option2: 30},
SECTION2: {option1, 2.0, option2: 3.0}}
That treats each section as a single piece.
But if you absolutely insist on flattening the dictionary, the right way
is not to concatenate the section name and the option name into a single
string, but to use a tuple (SECTION, option).
[snip]
In no way did I rewrite ConfigParser. I have a real job with time
pressures and I'm not so arrogant as to think I could whip something
up in an hour that would be anywhere close to correct.
I see that I wasn't as clear as I thought I was in my original post
as you are second person to think I was developing my own INI solution.
Copying somebody else's code and modifying it is still recreating an
existing solution. Python has an INI file parser. What does it not do that
you have to recreate it by creating your own version?
Oh, ironically, the recipe you borrowed in fact uses the Python
ConfigParser to do all the heavy work. All it really does is flatten the
ConfigParser nested dictionary into a flat dictionary. I fail to see the
advantage.
All I wanted to know was How do I compare two dictionaries to see if
they are equal?.
Yes, but I suspect what you _wanted_ to know and what you _needed_ to know
are different.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
