[Tutor] Prevent "Coder's Remorse"?

[Ron Phillips]

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