A proposal for attribute lookup failures

[MonkeeSage]

On Nov 18, 5:27 am, James Stroud <jstr... at mbi.ucla.edu> wrote:

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

That's what I meant about hiding the complexity of an attribute
failure. Though, sometimes implicit is acceptable (e.g., promotion of
int to float by __add__ when RHS is a float). Perhaps not here though.


> 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.

Ah. Good point. Hadn't thought of that.

--------

On Nov 18, 6:42 am, Arnaud Delobelle <arno... at googlemail.com> wrote:

> It changes how the following code executes:
>
> --------------------------
> def foo(x): return x.foo()
> foo(1)
> --------------------------
>
> * currently this raises AttributeError
> * under your proposal this code would fill the stack and raise a
> RuntimeError I guess.

I think it would be easy enough to detect and avoid cyclic references
like that (it's done in other instances in the language). An exception
could be thrown in such a case. But maybe it would be more difficult
than I imagine, leading to even further complexity (bad).

I think that, given that it hides a complex operation (which could
easily lead to abuse by the "unwashed masses"), and that in many cases
multiple lookups in the symbol table would be necessary before
termination (as in James' example above), as well as having to deal
with cases such as you mention, perhaps it's not such a good idea.

Off the cuff, it seemed like a nice feature (and still does, if it
could be implemented without the drawbacks). But such is life. :)

Regards,
Jordan