Proposal: default __init__

[Alex Martelli]

"Rainer Deyke" <root at rainerdeyke.com> wrote in message
news:2w%P5.195130$g6.88711735 at news2.rdc2.tx.home.com...
    [snip]
> I was under the misconceptions that getattr doesn't search the inheritance
> hierarchy for classes.  It seems to be a common misconception. :-(

You seem to be quite right on that point.


> > getattr fails).  A variant of getattr with this slightly
> > different semantics would have its uses... as long as
> > the currently-standard one also stays around:-).
>
> getattr3 seems more useful to me as the default, but changing the
semantics
> of A.b would probably break a lot of code.  Maybe in Python 3000?

If getattr's current semantics aren't used, and even aren't known,
giving it even richer and subtler ones by default seems iffy.

The ability to search a 'last-chance dictionary of defaults'
(rather than just return a fixed value) might be nice for
getattr (_and_ getitem), but I'm doubtful about the idea of
having a global-variable 'last-chance dictionary' be searched
as the default behavior.  Global variables may induce coupling
between subsystems, blah, blah.

What I really want is a 3-args getattr, with the 3rd attr
being a *lazy* lookup in the default-dictionary (the actual
lookup is only performed if needed).  There are several
ways to present/approximate such laziness in Python, but
I'd really like a direct, language-supported way, for this
AND umpteen other places where lazy is just what one wants...



> > I _suspect_ this is the kind of things you can do today w.
> > ExtensionClass, or other uses of metaclasses, but my
> > understanding thereof isn't deep enough, and I know
> > there are also some current limitations due to hardwired
> > PyInstance_Check calls in the Python sources...
>
> metaclasses (ab)use the inheritance syntax.  If I wanted that, I could
just
> use regular inheritance:

True: one way to get 'default implementation of certain
attributes' on a per-class basis is simply to use a mixin
class defining them as the rightmost base of the class.
How could I overlook this?!-)  It can also be seen as a
great way to get another dictionary into getattr's lookup.

However, this is NOT equivalent to what I was proposing,
since the "other dictionary" is NOT used 'only as a last
chance' -- rather, it can and does "interfere" with the
normal getattr mechanics when the class (that has used
the mixin, i.e. inherited from it) is used as non-rightmost
base of some other (which is what makes this break existing
code).  I was wondering if, with a metaclass instead, I
_could_ have the 'other dictionary' used ONLY "as a last
chance", i.e. only if the regular getattr (which runs over
the whole object) would otherwise raise AttributeError.


Imagine I had such a metaclass "CallUsLast"; now,

class A(CallUsLast):
    pass

class B:
    def foo(self):
        pass

class C(A,B):
    pass

now, in my feverish imagination,
    getattr(C,'foo')
would find B.foo, but
    getattr(C,'bar')
would find defaults['bar'] (if any, of course --
AttributeError unless defaults.has_key('bar')).

I don't know if this is feasible, but it might be seen
as Tres Cool if it were...


Alex