gh-153785: Generate AttributeError messages from context

[johnslavik]

I think this is the best place to do this. We do the same trick in KeyError.

This also fixed issue #143811 that motivated the current one.

• Issue: Generate AttributeError messages from their context #153785

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33667625 | 📁 Comparing 404359d against main (b4662e8)

  🔍 Preview build  

39 files changed · ± 39 modified

± Modified

• c-api/exceptions.html
• c-api/frame.html
• c-api/type.html
• c-api/typeobj.html
• c-api/veryhigh.html
• howto/abi3t-migration.html
• howto/logging-cookbook.html
• library/allos.html
• library/archiving.html
• library/ast.html
• and 29 more...

[pablogsal]

We dropped the .. versionchanged:: next note that documented the generated message. This is a user-visible change to str(), so I think we should keep a versionchanged here, no?

[johnslavik]

@serhiy-storchaka, do you agree on bringing it back?

[serhiy-storchaka]

We usually do not add versionchanged for minor changes like changed error message. Otherwise our documentation would be overwhelmed by them.

[vstinner]

The following code writes 'lazy_import' object has no attribute 'missing1': it mentions lazy_import rather than module 'asyncio'. But I don't think that AttributeError_str() would be the right place to reify the asyncio module!

lazy import asyncio

class RaiseWithName:
    def __getattr__(self, name):
        raise AttributeError(name)

try:
    getattr(globals()['asyncio'], "missing1")
except AttributeError as exc:
#    assert exc.obj is ...
    assert exc.name == "missing1"
    print(str(exc))

[jaraco]

I think this is the best place to do this. We do the same trick in KeyError.

This also fixed issue #143811 that motivated the current one.

* Issue: [Generate `AttributeError` messages from their context #153785](https://github.com/python/cpython/issues/153785)

"this" and "current one" is unclear here. Please update the PR description to describe the motivation. Also consider linking to the code for the trick in KeyError.

[jaraco]

I think this is the best place to do this. We do the same trick in KeyError.
This also fixed issue #143811 that motivated the current one.

* Issue: [Generate `AttributeError` messages from their context #153785](https://github.com/python/cpython/issues/153785)

"this" and "current one" is unclear here. Please update the PR description to describe the motivation. Also consider linking to the code for the trick in KeyError.

I used Claude to infer the motivations and update the description.

[jaraco]

It is the same trick KeyError already uses to wrap its key in repr() — see KeyError_str.

This trick has been applied to KeyError and AttributeError; should it be applied to other exceptions? Should it be implemented in such a way that the concern is shared across exceptions (explicitly or implicitly)?

[jaraco]

This trick has been applied to KeyError and AttributeError; should it be applied to other exceptions? Should it be implemented in such a way that the concern is shared across exceptions (explicitly or implicitly)?

Short answer, not really.

Details

(Analysis by Claude, on my behalf.)

A worthwhile question. Worth noting first that the two "tricks" only look alike at the surface (both override tp_str); underneath they differ:

• KeyError_str reformats what's already in args — wrapping args[0] in repr() so {}[''] prints KeyError: ''. Pure presentation.
• AttributeError_str synthesizes a message from side-channel context (obj/name) that the raiser never put in args, reconstructing what the interpreter attached out-of-band.

Only the second is the interesting reusable pattern ("I have structured context attributes; render them lazily instead of forcing every raise site to build the string"). The natural cohort there is NameError/UnboundLocalError (name), ImportError/ModuleNotFoundError (name, path). But both of those already build their full messages eagerly at the C raise site, so the problem AttributeError has — user __getattr__ implementations conventionally raising bare or name-only — barely exists for them.

So I'd lean against building a shared framework here:

• Two thin, differing data points; abstracting them would abstract over a coincidence of mechanism, not a shared concern.
• The templates ("object has no attribute" vs. "name is not defined" vs. "cannot import name from") are irreducibly per-type — only the dispatch around them could be shared.
• Every __str__ change is a compatibility surface (people do match on message text), and each type wants its own guard about when overriding is safe.

The one genuinely reusable piece is the guard predicate — "was this constructed with a default/absent message, or one that merely duplicates a structured field, so I'm safe to override?" (here: args of size 0, or size 1 equal to name). If anything gets factored out, I'd make it that small internal helper and leave each template local. Otherwise I'd revisit sharing only when a third genuine case actually lands.

[johnslavik]

The following code writes 'lazy_import' object has no attribute 'missing1': it mentions lazy_import rather than module 'asyncio'. But I don't think that AttributeError_str() would be the right place to reify the asyncio module!

lazy import asyncio

class RaiseWithName:
    def __getattr__(self, name):
        raise AttributeError(name)

try:
    getattr(globals()['asyncio'], "missing1")
except AttributeError as exc:
#    assert exc.obj is ...
    assert exc.name == "missing1"
    print(str(exc))

@vstinner, this code does not trigger the code path from this PR (RaiseWithName is unused). We could specialize this separately -- see #154196.

[serhiy-storchaka]

We usually do not add versionchanged for minor changes like changed error message. Otherwise our documentation would be overwhelmed by them.

[serhiy-storchaka]

LGTM. 👍