precedence of [] vs .

[Michael Tobis]

I wrote some code to test the precedence of getitem vs getattr; it
shows that getitem binds tighter.

I have been handed some code that relies on the observed behavior.
However, the Nutshell precedence list claims the opposite. Is the
Nutshell wrong or am I missing something or is this a bug?

class a(object):
def __getitem__(self,item):
return str(item)[:-1]

class b(object):
def __getattr__(self,item):
return str(item)[::-1]

Albert = a()
print Albert['abcd']
# prints 'abc'

Barney = b()
print Barney.abc
# print 'cba'

print Barney.Albert['abcd']
# raises TypeError; tries to evaluate 'treblA'['abcd']
# I expected 'cba' based on Nutshell 2d Ed p 50

 

[Calvin Spealman]

I wrote some code to test the precedence of getitem vs getattr; it
shows that getitem binds tighter.

I have been handed some code that relies on the observed behavior.
However, the Nutshell precedence list claims the opposite. Is the
Nutshell wrong or am I missing something or is this a bug?

class a(object):
def __getitem__(self,item):
return str(item)[:-1]

class b(object):
def __getattr__(self,item):
return str(item)[::-1]

Albert = a()
print Albert['abcd']
# prints 'abc'

Barney = b()
print Barney.abc
# print 'cba'

print Barney.Albert['abcd']
# raises TypeError; tries to evaluate 'treblA'['abcd']
# I expected 'cba' based on Nutshell 2d Ed p 50

attribute access (foo.bar) binds more tightly than subscripting (foo[bar]).

 

[Michael Tobis]

attribute access (foo.bar) binds more tightly than subscripting (foo[bar]).

That certainly looks right, and in retrospect I wonder that I even
doubted it. But even the official docs seem to me to specify
otherwise:

http://docs.python.org/ref/summary.html

mt

 

[Terry Reedy]

attribute access (foo.bar) binds more tightly than subscripting (foo[bar]).

That certainly looks right, and in retrospect I wonder that I even
doubted it. But even the official docs seem to me to specify
otherwise:

http://docs.python.org/ref/summary.html

For 3.0, the error message for Barney.Albert)['abcd'] is slightly
different -- TypeError: string indices must be integers -- but the
effect is the same. I submitted
http://bugs.python.org/issue3558

tjr

 

[Carl Banks]

attribute access (foo.bar) binds more tightly than subscripting (foo[bar]).

That certainly looks right, and in retrospect I wonder that I even
doubted it. But even the official docs seem to me to specify
otherwise:

http://docs.python.org/ref/summary.html

I think the summary is correct (am not going to bother to double-
check), but there's a subtle point you're missing. Here is a
simplified explanation.


The syntax for subscript operator is:

expression [ expression ]


The syntax for attribute access is:

expression . symbol


The subtle point here is that the symbol that comes after the dot is
NOT an expression, and therefore can't serve as the first expression
in the subscript opreator rules.

The effect of this is that the grouping a.(b[c]) is impossible.


Carl Banks

 

[Fredrik Lundh]

Calvin Spealman wrote:e

attribute access (foo.bar) binds more tightly than subscripting (foo[bar]).

no, they have the same binding power; here's the relevant part of the
grammar:

trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME

note however that "." only binds to a name, not a full expression (as
Carl noted).

the summary at http://docs.python.org/ref/summary.html is broken; the
source code for that page looks like this:

...
\hline
\lineii{\code{+}, \code{-}}{Addition and subtraction}
\hline
\lineii{\code{*}, \code{/}, \code{\%}}
{Multiplication, division, remainder}
\hline
\lineii{\code{+\var{x}}, \code{-\var{x}}} {Positive, negative}
\lineii{\code{\~\var{x}}} {Bitwise not}
\hline
\lineii{\code{**}} {Exponentiation}
\hline
\lineii{\code{\var{x}.\var{attribute}}} {Attribute reference}
\lineii{\code{\var{x}[\var{index}]}} {Subscription}
\lineii{\code{\var{x}[\var{index}:\var{index}]}} {Slicing}
\lineii{\code{\var{f}(\var{arguments}...)}} {Function call}
\hline
...

which indicates that the author intended "." and "[" to appear in the
same box, but got overruled by the Tex->HTML conversion tool.

(if someone has the bandwidth, please submit a documentation bug).

</F>

 

[Fredrik Lundh]

I think the summary is correct (am not going to bother to double-
check), but there's a subtle point you're missing. Here is a
simplified explanation.

the rendered summary is broken; see my other post.

</F>

 

[Terry Reedy]

Calvin Spealman wrote:e

attribute access (foo.bar) binds more tightly than subscripting
(foo[bar]).

no, they have the same binding power; here's the relevant part of the
grammar:

trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME

note however that "." only binds to a name, not a full expression (as
Carl noted).

the summary at http://docs.python.org/ref/summary.html is broken; the
source code for that page looks like this:

...
\hline
\lineii{\code{+}, \code{-}}{Addition and subtraction}
\hline
\lineii{\code{*}, \code{/}, \code{\%}}
{Multiplication, division, remainder}
\hline
\lineii{\code{+\var{x}}, \code{-\var{x}}} {Positive, negative}
\lineii{\code{\~\var{x}}} {Bitwise not}
\hline
\lineii{\code{**}} {Exponentiation}
\hline
\lineii{\code{\var{x}.\var{attribute}}} {Attribute reference}
\lineii{\code{\var{x}[\var{index}]}} {Subscription}
\lineii{\code{\var{x}[\var{index}:\var{index}]}} {Slicing}
\lineii{\code{\var{f}(\var{arguments}...)}} {Function call}
\hline
...

which indicates that the author intended "." and "[" to appear in the
same box, but got overruled by the Tex->HTML conversion tool.

(if someone has the bandwidth, please submit a documentation bug).

Already done: http://bugs.python.org/issue3558

I took the liberty of cutting and pasting your explanation, and added
""x.attribute, x[index], x[index:index], f(arguments...)"
will not fit in the Operator column. I suggest adding
"[Next 4 have same precedence] Trailers"
with the next four lines indented 3 or 4 spaces in each column."

Feel free to add more if you think more is needed.

Terry Jan Reedy