Alan
Thanks for the thorough reply.
> Hi Ron, I'm confused and may be missing something but it
> sounds to me like a classic tree structure that you are trying
> to build for each module.
It seems like a tree to me.
> I''m not sure why you put filling the database into a separate
> function rather than as a method of the Database class, it
> could then be called from the init method. This would give
> it direct access to the Database attributes.
This structure evolved. As I solved one problem, I ran into another,
and eventually ended up with the current design. I know it's not
ideal, but it's the result of my spotty knowledge of Python and what I
was able to locate in the assorted documentation that I have skimmed
through looking for things that looked relevant.
> Also I don't understand why you need the componentlist
> name. What is this used for? The name of the list is surely
> an internal variable within the module of no relevance to
> the outside world?
I was hoping to eventually put all of the data in a separate Python
module. That way if it ever changed, I could just edit that file.
> I'm also not clear about the database structure. Is the one
> represented here the final striucture - ie a set of Python lists.
> Or will you eventually be loading the data from a config file
> or a relational database at some point in the future?
I'm not talking to a SQL database or anything like that. I just have
this chunk of data. It will change occasionally, so I need a
convenient place to edit the data
> If it stays as it is then the whole design seems overly
> complex since you could simply load the data as part of
> the object construction/instantiation process, something like this:
>
> ModuleList = [
> Module( "Motherboard",
> [Component("Camera",
> [Command(p1,p2,p3),
> Command(p4,p5)]),
> ]),
> Module("Controller",
> [Component("Major Controller",
> [Command(....),....]),
> Component("Minor Controller",
> [Command(....),....]),...
> ]),
> Module("End User",
> [Component("xMotor", [Command(...),...]),...
> ])
> ]
That looks similar to something I did before and had to abandon. I
suspect my earlier attempt was flawed in some way. The above might
work.
> I suspect the use of a dictionary might be beneficial too.
Dictionaries are only pairs of data. I assume a list can be one of
those elements, but I couldn't figure out how to make it work in the
structure I presented.
> However if the data varies at runtime and you have to read it
> from an external source that approach won't work.
It doesn't.
> Why not a dictionary of modules keyed by module name?
I wanted to make the methods flexible enough that I wouldn't have to
edit every method if the module list ever changed. I guess I don't
understand how a dictionary works in this situation.
> Why not write constructors that take a list as a parameter.
> The constructor can manage its own list and the higher
> level constructor just passes in the appropriate list. That way
> each class only needs to know about the data at the level
> it is responsible for. So the Module class might look a bit like:
>
> class Module:
> def __init__(self, name, componentlist):
> self.components = {}
> self.name = name
> for component in componentlist:
> self.components[component[0]] = Component(component)
>
> This implies that the component list is structured as a list of tuples.
I originally had tuples, but you can't access individual elements.
E.g., give me the second item in each tuple. I see you're using a
dictionary in the above structure. Maybe that solves that issue. I'll
have to give the above a try and see if it works.
>> I have object "db.mb". I have iterator "shortmod" with a value of
>> "mb". Why can't I call "db.shortmod"?
>
> You can use db.getattr(shortmod)
That doesn't work. It tells me "Database instance has no attribute
'getattr'".
> but I think its easier and clearer in this case to use:
>
> db.Modules[shortmod]
If Modules is a class name, how am I able to call it like that? I
plugged that into my program, and it said:
"AttributeError: Database instance has no attribute 'Modules'"
> I think you can make it a much closer equivalent than you
> have at present, and I think that by breaking up the fill db
> function and moving responsibility into the classes that it
> will be much simplified. And use dictionaries rather than lists.
>
> HTH
IDD
(it definitely does!)
I have to run off to work now. I'll try your suggestions when I get
there. Thanks a whole lot!!
Ron
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
