Ok, I have three diverse answers from three of the tutors that I respect
most.
Kent Johnson's approach: subclass dict and overloads the __getitem__ ,
__setitem__, and __delitem__ methods.
Alan G's idea:
". . .
Get the init method to update a global (or class based)
list of instances and write a del() method that removes
itself.
Then a class method can iterate that instance list
doing whatever it needs to do..."
And Danny Yoo's hierarchical structure:
". . .
The idea here is that we impose some structure among the points. We
can
keep a central Point that has a set of child points within its
satellite.
######
>>> centralPoint = Point(40, -81, {})
>>> satellitePoint = Point(40, -81, {}, centralPoint)
######
. . ."
Very clever ideas, as far as I can tell. I need to play with all three
of them so that I understand them thoroughly. I think that once I do,
I'll be able to say I really understand OOP in Python! I believe that
any one of these approaches will do what I need, though, so maybe it
comes down to style.
Maybe I should explain why I thought I wanted this object. I am trying
to read, edit, and write shapefiles (actually, a shapefile is a
collection of 3-6 files having the same filename, but different
extensions. It's a legacy format that still gets a lot of use in
geography.)
One of the constituent files in a shapefile is a variant of Xbase,
which knows nothing about NULL, so I have to provide some value in
every column for every record when I write them. I thought that having a
data structure that enforces a common set of "fields", the application
would be more robust when it's being edited. (Prevent me from deleting
an item for one record and not others, or adding a field to a record
without adding at least some default value to all the others.)
I just thought about it, but a CSV file has kind of the same problem.
Thanks, everyone; this will be a real education, however I go!
Ron
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
