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 ) _______________________________________________ Zope maillist - Zope@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 )