inspect.getsource (findsource) not working as expected when duplicate class is used

[Viicos]

Bug report

Consider the following example:

import inspect

class Model:
    a = 1

class Model:
    a = 2

print(Model.a)
#> 2
print(inspect.getsource(Model))
#> class Model:
#>     a = 1

I think we should expect the last class to be used (it works as expected if we use functions instead of classes).

This issue was raised in an external project:

• inspect.getsourcelines is wrong octoml/synr#13

And I'm facing this issue while working on:

• Extract attribute docstrings for FieldInfo.description pydantic/pydantic#6563

Let me know if this should be fixed, I'll take a deeper look at what was done in #10307 and see if I can make a PR

Your environment

• CPython versions tested on: 3.11.4
• Operating system and architecture: Ubuntu

Linked PRs

• gh-106727: Make inspect.getsource smarter for class for same name definitions #106815
• gh-106727: Add __module__ check for inspect.getsource(cls) #106968

[gaogaotiantian]

The method has already been changed from regex to ast. I can work on the PR if you are okay with it. If you want to fix this yourself, the code piece is at the similar place, just switched to an ast based searching.

[gaogaotiantian]

Just BTW, the last class may not be the one you need.

if cond:
    class A:
        ...
else:
    class A:
        ...

We could probably need some heuristics to figure out which class it should be.

[Viicos]

The method has already been changed from regex to ast. I can work on the PR if you are okay with it. If you want to fix this yourself, the code piece is at the similar place, just switched to an ast based searching.

Yes by look at what was done in #10307 I meant improve this ast based search.

We could probably need some heuristics to figure out which class it should be.

I wonder if this is possible depending of the condition evaluated.

[gaogaotiantian]

Oh sorry I did not look at the PR thoroughly. I saw the word "regex" and thought it was improving the regex method.

classes do not have useful compile time information with it as far as I know which makes this tricky - that's why I said we probably need some heuristics. I doubt if we can make this work:

if runtime_cond:
    class A:
        pass
else:
    class A:
        pass

They are indistinguishable. We can, however, try to figure out which class it is by some "guessing" like reading their methods. Let me know if this is out of your comfortable zone and you'd like me to work on it, I'm kind of familiar with the area. Otherwise, let me know if you have any question about the implementation.

[Viicos]

I'll try to take a look, I'm not that familiar with ast but I'll try to come up with something (this is a good opportunity to learn more about it), we will then be able to work on this together if I encounter any blocking points

[Viicos]

Actually while I see how this could be implemented, I don't really see which attributes should be used to guess the right class. @gaogaotiantian if you have something in mind I'll be pleased to see a PR

[gaogaotiantian]

No worries, I'll work on it, it can be a bit tricky.

[Viicos]

No worries, I'll work on it, it can be a bit tricky.

Yeah I was first thinking maybe use the values from __dict__, but we have to make sure not to include attributes set by a potential metaclass