type checking

[Alex Martelli]

Carlo v. Dango wrote:

>> I am not trying to impress anyone.  Give me a problem and I can
>> lay a wager I can do it in python and deliver you the beta code in
>> two weeks. Let that be a fresh problem btw. Give me another two
>> weeks and I can deliver you commercial quality code without using
>> a debugger.
>> Try me.
>>
>> -Anand
> 
> please show me a solution where pythons inner class instances has an
> 'outer scope' where it can access the fields and methods of its outer
> class instance. Similar to inner classes in java, and similarly to methods
> inside methods in python..

It seems to me you keep confusing ACCESS with RE-BIND.

"methods inside methods", in Python, cannot re-bind variables in the
outer scope.  If you really want to be similar to THAT, it's trivial:
having just __getattr__ and no __setattr__ at all should suffice.

If what you want is something extremely intricate and non-obvious
such as:

    in the inner classe, self.x = y means self.outer.x = y IF it
    so happens that self.outer had an attribute x already defined
    at that specific point in time; but it changes meaning to a
    normal self.x = y if self.outer did NOT have that attribute
    at that precise instant

(which may be a caricature of how somebody, who just doesn't get
the _dynamic_ nature of binding and attributes in Python, and is
dead set on kludging up something that would only make sense if
that nature was static instead, might "reason"), that' easy:

    def __setattr__(self, name, value):
        if hasattr(self.outer, name): setattr(self.outer, name, value)
        else: object.__setattr__(self, name, value)

(and use object.__setattr__(self, 'outer', outer) in __init__ --
also inherit your inner class from object, obviously).

The problem is not how to implement ANY precise specification:
it's coming up with a specification of what exactly you want to
happen, that makes sense and provides SOME usefulness within the
rest of how Python works.  I can't see the above spec and its
implementation meeting this common-sense test (but then, I cannot
see any spec that vaguely resembles any of your several descriptions
of what you want that does it, either).

E.g., say the two objects are outer and inner, with inner delegating
to outer as above.  With the above specs:

inner.x = 23   #  say outer has no x attribute at this instant
outer.x = 45   #  but now of course it has acquired it
inner.x = 67   #  and so THIS assignment delegates

now a "print inner.x, outer.x" would print 23, 67 -- the inner.x
remains "stuck" at the last value you assigned for it BEFORE
outer.x sprung into existence, any further assignment to inner.x
affects outer.x instead.  A "del outer.x" would suddenly make
further assignments to inner.x sensible again (until something
else assigns to outer.x, when assignments to inner.x become crazy
again, as per specs).

There may be application usefulness in this behavior, maybe, but
if so I'm definitely failing to SEE it...


Alex