checking if an object IS in a list

[nicolas.pourcelot]

Yes, I may subclass dict, and change its __getitem__ and __setitem__
methods, instead of changing objets __setattr__ and __getattr__... But
I prefer

sheet.objects.A = Point(0, 0) than
sheet.objects["A"] = Point(0, 0)

But with computed names isn't the difference more like

setattr(sheet.objects, name, Point(0, 0))
vs.
sheet.objects[name] = Point(0, 0)

and

getattr(sheet.objects, name)
vs.
sheet.objects[name]

Or do you really have ``sheet.objects.A`` in your code, in the hope that
an attribute named 'A' exists?

I wrote 'type' here by mistake, but I used 'isinstance' in my code. ;-)

Doesn't change the "code smell".  OOP approach would be a method on the
geometric objects that know what to do instead of a type test to decide
what to do with each type of geometric object.

Ciao,
        Marc 'BlackJack' Rintsch

Thank you for your advises, it's very interesting to have an external
point of view.

No, I have not anything like 'sheet.objects.A' in the library code,
but I use then the library in different programs where things like
sheet.objects.A sometimes occur.
However, since it is not so frequent, I may indeed subclass dict, and
change __getitem__, __setitem__ and __delitem__, and then redirect
__getattr__, __setattr__, __delattr__ to previous methods... This
would not break library external API, and it may speed-up a little
internal stuff.

I'm not very expert in OOP ; imho it's largely a mean and not a goal.
On one hand, 'a method on the geometric objects that know what to do'
would require them to contain some code concerning the object
manager... I don't like that very much. On the other hand, object
manager should not rely on object's implementation... I will think
about that.

Thank you all of you for your answers.
I'm sorry I may not have time to reply further, it was interesting
(even if it's a bit difficult for me to write clearly in english ;-))