Design question.

Dave Angel davea at
Tue Jul 21 02:47:56 CEST 2009

Lacrima wrote:
> On Jul 20, 4:05 pm, Jean-Michel Pichavant <jeanmic... at>
> wrote:
>> Lacrima wrote:
>>> Hello!
>>> I am newbie in python and I have really simple question, but I need
>>> your advice to know how to do best.
>>> I need to store a number of dictionaries in certain place. I've
>>> decided to store them in a separate module.
>>> Like this:
>>> -----------------------
>>> dict1 =....}
>>> dict2 =....}
>>> dict3 =....}
>>> Then, when I need any dictionary, I can access it:
>>> import dicts
>>> dicts.dict1
>> <snip>
> Hi, Jean-Michel!
> Thanks for your answer.
> I am not going to have names like and dict1,dict2. That was
> just example. I wanted to know if it is correct to have dictionaries
> on a module level. Now I know that this is correct. I want to collect
> in one module a number of dictionaries, every of which describes a
> separate web service. And my function in another module will import
> required dictionary, depending on what web service should be used.
> Thanks again for the help.
> With regards,
> Max.
> (sorry if my English isn't very proper)
It makes a lot of sense to store several dictionaries in a module, if 
they describe parallel things, or alternate ways of accessing something 
(like web services).

However, you might want to consider how they'll be accessed.  If another 
module is going to "import required dictionary," then you have some 
means of selection.  Perhaps that selection should be in the same 
module, or at least the data structure to select it should be in the 
same module.

Let's say you have four choices right now.  And you add a fifth later.  
Do you want to have to edit both the "function in the other module" as 
well as this module?

This is similar to a feature that some programs have, "plug-ins."   
There a customer can add an additional runtime just by dropping a new 
.py file in the appropriate directory, and the program will find it and 
add it to its "list of features."

So I'm just suggesting you figure out how the program might evolve, and 
set up the data so changes may be localized, if practical.  This turns 
out usually to be parallel to the notion of naming things and grouping 
them by similarity of functionality.


More information about the Python-list mailing list