On Mon, Sep 07, 2009 at 09:12:14AM +0200, Tobias Weber wrote:
> On 07.09.2009, at 00:29, Oleg Broytmann wrote:
>
> > Now, much later after _init(), the instance of class C got the
> > attribute 'name'.
>
> I know. The problem is that dir() lists it before that, which, as I
> wrote, breaks any code using introspection.
dir() didn't list *it* - dir() listed a property from the class - print
self.__class__.__dict__ and see it's there. But having a property in the
class doesn't guarantee it wouldn't raise an exception when called. In case
of properties dir() is not a substitute for hasattr().
> SQLObject passes
> internally inconsistent objects to _init.
I don't think it's inconsistent. Any property is free to raise any
exception. Think about a property that raises UnicodeError, or
socket.error, or KeyboardInterrupt.
> In my case, a library implementing the observer pattern looks for a
> certain kind of method using a module that comes with Python:
>
> inspect.getmembers(self, predicate=lambda m: inspect.ismethod(m))
>
> Internally that iterates over dir() and does isinstance(getattr).
Looks like a bug in that library. It must distinguish plain attributes
from properties.
> Code
> like this should never fail.
Really? Even if dir() detects a property that raises an exception? Any
exception?
> The ugly part is that the reason dir() mentions 'name' is because it's
> in the __dict of the parent class, as a StringCol instance. Normally
> getattr does search there and would just return that StringCol. I
> guess the error stems from SQLObject overriding __getattribute__ or
> something with an implementation that is aware of columns, but at the
> time of _init is not defined. I think it should at all times behave
> like a normal Python object and just return StringCol if it doesn't
> have a value from the table yet.
I don't think so. After you have declared 'name' is a StringCol
self.name is supposed to be a property that accepts and returns strings,
not the StringCol instance. What are you going to do with those StringCol
instances?
> Or also override __dir__ and only
> list magic members when they actually work.
Impossible now - __dir__ is only used in Python 2.6+, and SQLObject still
supports 2.4.
And I don't think it's necessary. Any property is free to raise any
exception.
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
