checking if an object IS in a list

[nicolas.pourcelot at gmail.com]

On 20 juil, 07:17, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
> On Sat, 19 Jul 2008 13:13:40 -0700, nicolas.pourcelot wrote:
> > On 18 juil, 17:52, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
> >> On Fri, 18 Jul 2008 07:39:38 -0700, nicolas.pourcelot wrote:
> >> > So, I use something like this in 'sheet.objects.__setattr__(self,
> >> > name, value)':
> >> > if type(value) == Polygon:
> >> >     for edge in value.edges:
> >> >         if edge is_in sheet.objects.__dict__.itervalues():
> >> >             object.__setattr__(self, self.__new_name(), edge)
>
> >> > Ok, I suppose it's confused, but it's difficult to sum up. ;-)
>
> >> You are setting attributes with computed names?  How do you access them?
> >> Always with `gettattr()` or via the `__dict__`?  If the answer is yes, why
> >> don't you put the objects the into a dictionary instead of the extra
> >> redirection of an objects `__dict__`?
>
> > 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?
>
> >> Oh and the `type()` test smells like you are implementing polymorphism
> >> in a way that should be replaced by OOP techniques.
>
> > 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 ;-))