[Zope] Re: Problem with hasattr() and Zope 2.8.1

Doyon, Jean-Francois Jean-Francois.Doyon at CCRS.NRCan.gc.ca
Wed Oct 5 14:59:53 EDT 2005


Alec,

Heh, thanks for the reply, I somehow have been using python for a few years
now without ever running into that!

I'm afraid I'm still baffled by it, mostly because I've used attributes
named in such a manner up until now without problem ...

>From what you're saying I guess hasattr() being a built-in function, it's
not recognized as part of the instance, so the mangling doesn't work right?

But then, why does this code work ok?

class CrosslingualSupport:
    """ Mix-in class to provide content objects with support for
        cross-lingual properties when needed.
    """

    def clearCrosslingualAttributes(self, lang):
        """ For a given language, remove all internal attributes related to
it. """
        for propertyname in [ propname for propname in
self.__multilingualproperties__.keys() if
self.__multilingualproperties__[propname][1] == True ]:
            attname = '__' + propertyname + '_' + lang
            if hasattr(self, attname): delattr(self, attname)

As you see on the last line, I'm doing a hasattr() on an attribute who's
name starts with 2 underscores, and it works fine in this case (has been for
weeks, if not months).

BUT, in my other situation, it isn't!!  Heck, I think I even tried
getattr(self, '__attribute') and it didn't work right.  ONLY
self.__attribute seems to work.  But then, I'm back to wondering why the
above works fine, and worry that something's going to come bite me later ...

I'm starting to wonder if subclassing and/or my usage of metaclasses might
be a cause for the different behavior?? Either that, or there's something
buggy with zope's versions of get/set/has/delattr ...

Even though I've gotten around it, I'll keep looking, it's driving me nuts
:)

J.F.

On Friday 30 September 2005 12:49 pm, Doyon, Jean-Francois wrote:
> Hello,
>
> I'm using new-style classes and properties to implement multilingual
> support in my objects. I might therefore have something like:
>
> mything = property(__get_mything)
>
> def __get_mything:
>     return self.__mything_en
>
> (Extremely simplified!)
>
> This works fine.
>
> Now however I'm discovering that doing a hasattr() on anything that starts
> with 2 underscores always returns false!
>
> So hasattr(self, '__thumbnail') doesn't work as expected, but
hasattr(self,
> '_thumbnail') DOES! (All other things being equal of course).

This is actually a feature of python.  Names starting with '__' are mangled
by 
the interpreter so that they are not directly accessible outside the class 
itself; it is an attempt to simulate private class members.  If you are 
finding yourself in need of using a variable that someone else has decided 
needed to be named with '__' then you may want to rethink what you are
doing.  
It is somewhat rare that a python programmer would use this trick, so you 
should probably heed the warning and avoid using it if at all possible.  If 
these are methods that you created then just rename them to use a single or 
preferably no underscores if you need to use them from outside the class 
itself (a single underscore is still bad form, as '_' is an indicator that a

variable is intended to be private and a suggestion that it only be used in 
the class itself).

Alec Mitchell
_______________________________________________
Zope maillist  -  Zope <at> zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


More information about the Zope mailing list