>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
GvR> - Do you really think that JimF would do away with
GvR> ExtensionClasses if __findattr__ was intruduced? I kinda
GvR> doubt it. See [*footnote]. It seems that *using*
GvR> __findattr__ is expensive (even if *not* using is cheap :-).
That's not even the real reason why JimF wouldn't stop using
ExtensionClass. He's already got too much code invested in EC.
However EC can be a big pill to swallow for some applications because
it's a C extension (and because it has some surprising non-Pythonic
side effects). In those situations, a pure Python approach, even
though slower, is useful.
GvR> - Why is deletion not supported? What if you want to enforce
GvR> a policy on deletions too?
It could be, without much work.
GvR> - It's ugly to use the same call for get and set. The
GvR> examples indicate that it's not such a great idea: every
GvR> example has *two* tests whether it's get or set. To share a
GvR> policy, the proper thing to do is to write a method that
GvR> either get or set can use.
I don't have strong feelings either way.
GvR> - I think it would be sufficient to *only* use __findattr__
GvR> for getattr -- __setattr__ and __delattr__ already have full
GvR> control. The "one routine to implement the policy" argument
GvR> doesn't really hold, I think.
What about the ability to use "normal" x.name attribute access syntax
inside the hook? Let me guess your answer. :)
GvR> - The PEP says that the "in-findattr" flag is set on the
GvR> instance. We've already determined that this is not
GvR> thread-safe. This is not just a bug in the implementation --
GvR> it's a bug in the specification. I also find it ugly. But
GvR> if we decide to do this, it can go in the thread-state -- if
GvR> we ever add coroutines, we have to decide on what stuff to
GvR> move from the thread state to the coroutine state anyway.
Right. That's where we've ended up in subsequent messages on this thread.
GvR> - It's also easy to conceive situations where recursive
GvR> __findattr__ calls on the same instance in the same
GvR> thread/coroutine are perfectly desirable -- e.g. when
GvR> __findattr__ ends up calling a method that uses a lot of
GvR> internal machinery of the class. You don't want all the
GvR> machinery to have to be aware of the fact that it may be
GvR> called with __findattr__ on the stack and without it.
Hmm, okay, I don't really understand your example. I suppose I'm
envisioning __findattr__ as a way to provide an interface to clients
of the class. Maybe it's a bean interface, maybe it's an acquisition
interface or an access control interface. The internal machinery has
to know something about how that interface is implemented, so whether
__findattr__ is recursive or not doesn't seem to enter into it.
And also, allowing __findattr__ to be recursive will just impose
different constraints on the internal machinery methods, just like
__setattr__ currently does. I.e. you better know that you're in
__setattr__ and not do self.name type things, or you'll recurse
forever.
GvR> So perhaps it may be better to only treat the body of
GvR> __findattr__ itself special, as Moshe suggested.
Maybe I'm being dense, but I'm not sure exactly what this means, or
how you would do this.
GvR> What does Jython do here?
It's not exactly equivalent, because Jython's __findattr__ can't call
back into Python.
GvR> - The code examples require a *lot* of effort to understand.
GvR> These are complicated issues! (I rewrote the Bean example
GvR> using __getattr__ and __setattr__ and found no need for
GvR> __findattr__; the __getattr__ version is simpler and easier
GvR> to understand. I'm still studying the other __findattr__
GvR> examples.)
Is it simpler because you separated out the set and get behavior? If
__findattr__ only did getting, I think it would be a lot similar too
(but I'd still be interested in seeing your __getattr__ only
example). The acquisition examples are complicated because I wanted
to support the same interface that EC's acquisition classes support.
All that detail isn't necessary for example code.
GvR> - The PEP really isn't that long, except for the code
GvR> examples. I recommend reading the patch first -- the patch
GvR> is probably shorter than any specification of the feature can
GvR> be.
Would it be more helpful to remove the examples? If so, where would
you put them? It's certainly useful to have examples someplace I
think.
GvR> There's an easy way (that few people seem to know) to cause
GvR> __getattr__ to be called for virtually all attribute
GvR> accesses: put *all* (user-visible) attributes in a sepate
GvR> dictionary. If you want to prevent access to this dictionary
GvR> too (for Zope security enforcement), make it a global indexed
GvR> by id() -- a destructor(__del__) can take care of deleting
GvR> entries here.
Presumably that'd be a module global, right? Maybe within Zope that
could be protected, but outside of that, that global's always going to
be accessible. So are methods, even if given private names. And I
don't think that such code would be any more readable since instead of
self.name you'd see stuff like
def __getattr__(self, name):
global instdict
mydict = instdict[id(self)]
obj = mydict[name]
...
def __setattr__(self, name, val):
global instdict
mydict = instdict[id(self)]
instdict[name] = val
...
and that /might/ be a problem with Jython currently, because id()'s
may be reused. And relying on __del__ may have unfortunate side
effects when viewed in conjunction with garbage collection.
You're probably still unconvinced <wink>, but are you dead-set against
it? I can try implementing __findattr__() as a pre-__getattr__ hook
only. Then we can live with the current __setattr__() restrictions
and see what the examples look like in that situation.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4