> It is not reasonable to expect an error to be generated at runtime:
> because each and every object would have to be queried as to whether
> they have the attribute to know if there is ambiguity on each and every
> reference to an attribute.

It absolutely is:
if you're using an "inferred" syntax like

in object:
    .value

but there are multiple such objects to look at, Python immediately throws an error, before doing any kind of lookup. Hence the error doesn't say "I couldn't find the attribute x on any object" but instead "There's ambiguity so I didn't even try".

On Mon, May 2, 2016 at 6:19 PM MRAB <python@mrabarnett.plus.com> wrote:
On 2016-05-02 23:06, Erik wrote:
> On 02/05/16 23:00, Joshua Morton wrote:
>> It should be a name error, perhaps 'Accessed object's name cannot be
>> inferred', or a similar error to UnboundLocalException.
>
> You are missing the point.
>
> It is not reasonable to expect an error to be generated at compile time:
> because the compiler has no way of knowing what attributes will exist on
> the objects at runtime.
>
> It is not reasonable to expect an error to be generated at runtime:
> because each and every object would have to be queried as to whether
> they have the attribute to know if there is ambiguity on each and every
> reference to an attribute.
>
> The question of which error or warning or exception should be generated
> is moot ;)
>
You _don't_ have to know attributes are available. It's as simple(?) as:
when it sees the leading-dot notation, it checks how many expressions
the enclosing 'with' was followed by.

For example:

     with something:
         .foo()

is OK (the 'with' has 1 expression), but:

    with first_thing, second_else:
        .foo()

might not be OK (the 'with' has 2 expressions).

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/