A proposal for attribute lookup failures

[James Stroud]

MonkeeSage wrote:
> Proposal:
> 
>   When an attribute lookup fails for an object, check the top-level
> (and local scope?) for a corresponding function or attribute and apply
> it as the called attribute if found, drop through to the exception
> otherwise. This is just syntactic sugar.
> 
> 
> Example:
> 
>   a = [1,2,3]
> 
>   a.len()
>   # -> fails,
>   # -> finds len() in the top-level symbol table,
>   # -> applies len(a)
>   # -> 3
> 
>   a.foobar()
>   # -> fails,
>   # -> no foobar() in scope,
>   # -> raise NameError
> 
> 
> Benefits:
> 
>   - Uniform OO style. Top-levels can be hidden as attributes of data.
> Most of the top-level functions / constructors can be considered as
> attributes of the data; e.g., an int() representation of a string can
> be considered as _part_ of the semantics of the string (i.e., one
> _meaning_ of the string is an int representation); but doing it this
> way saves from storing the int (etc) data as part of the actual
> object. The trade-off is speed for space.
> 
>   - Ability to "add" attributes to built-in types (which is requested
> all the time!!) without having to sub-class a built-in type and
> initialize all instances as the sub-class. E.g., one can simply define
> flub() in the top-level (local?) namespace, and then use "blah".flub()
> as if the built-in str class provided flub().
> 
>   - Backwards compatible; one can use the top-level functions when
> desired. No change to existing code required.
> 
>   - Seemingly trivial to implement (though I don't know much C). On
> attribute lookup failure, simply iterate the symbol table looking for
> a match, otherwise raise the exception (like current implementation).
> 
> 
> Drawbacks:
> 
>   - Could hide the fact that an extra (On?) lookup on the symbol table
> is necessary for attribute lookup failure. (Maybe there could be a
> switch/pragma to enable (or disable) the functionality?)
> 
>   - As above, attribute lookup failure requires an extra lookup on the
> symbol table, when normally it would fall through directly to
> exception.
> 
>   - ???
> 
> 
> Disclaimer:
> 
>   I realize that very often what seems good to me, ends up being half-
> assed, backwards and generally bad. So I'd appreciate input on this
> proposition. Don't take it that I think the idea is wonderful and am
> trying to push it. I am just throwing it out there to see what may
> become of it.

It would be unoriginal of me to suggest that this violates the explicit 
is better than implicit maxim. But it does.

Also, you have picked the perfect use case for a counter argument:

py> class NoLen(object):
...   pass
...
py> len(NoLen)
------------------------------------------------------------
Traceback (most recent call last):
   File "<ipython console>", line 1, in <module>
<type 'exceptions.TypeError'>: object of type 'type' has no len()

So this proposal would send the interpreter through two cycles of trying 
to find the proper attribute before it failed.

Plus, I probably haven't even raised the best arguments against it, but 
my feeling is that it has serious problems and is better left out of the 
language.

But it is an interesting idea nonetheless.

James


-- 
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com