Consider the following program

# example.py
one = 1
two = "two"
a = [one
    .
    two]

Running this program with Python versions before 3.10, yields the following traceback:

Traceback (most recent call last):
  File "C:\Users\andre\example.py", line 3, in <module>
    a = [one
AttributeError: 'int' object has no attribute 'two'

The line shown correctly includes the 'int' object. I have verified that this is the case for Python 3.6 to 3.9 inclusively.

However, with Python version 3.10.0b3, the following traceback is generated:

Traceback (most recent call last):
  File "C:\Users\andre\example.py", line 5, in <module>
    two]
AttributeError: 'int' object has no attribute 'two'

I believe this is the outcome of https://bugs.python.org/issue39316 which I filed, so I'm pulling in . Naturally I think the new behaviour is not a bug but a feature.

I think it's more important for the traceback to show the attribute access (`two`) than the value (`one`). That's what the frame was doing at the time which led to the error.

The difference becomes even more important when calling a method with no arguments. Given this script:

class A:
    def b(self):
        1 / 0


x = (
    A()
        .b()
)


The 3.9 traceback points to the line with `A()` in the `<module>` frame, while 3.10 correctly points to `.b()`, which makes the following line 'in b' make more sense.

Where the old behaviour has really gotten to me is when I run the pycharm debugger and put a breakpoint on the .b() line and it never gets hit. Not being sure what lines 'count', I sometimes defensively put breakpoints on a cluster of lines, then spend more time removing them later. Having that fixed in 3.10 is great.

(meant to say "so I'm pulling in @Mark.Shannon)

Mark, take a look as soon as possible as beta4 is this week

This is a tricky one.
Which is the "correct" line appears to be subjective.

I'm inclined to leave it as is, as the tracing sequence seems better in the case of method chaining.
See https://github.com/python/cpython/blob/main/Lib/test/test_compile.py#L890

While I filed the original report, I am in agreement that accurate information for debugging tools is definitely more important than the quick summary shown in the traceback, and that the change likely represents an improvement in situations more realistic than the contrived example I gave.

> I'm inclined to leave it as is

I am fine with that, if you think this is not a bug, close the issue and remove the release blocker :)