You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Suggestions: check for name collisions between modules and items in a module #144285
When the suggestion finds a match like this, it should also check to make sure the module name and the suggestion don't clash. Perhaps it should also be able to suggest datetime.datetime.now?
Detecting the clash would require checking the scope for the name, too (locals, globals, etc).
Considering what Pablo said earlier, we'd likely want to avoid this either.
Maybe we could just rephrase the error message? "Did you mean 'datetime.now' instead of 'now'"?
AttributeError: module 'datetime' has no attribute 'now'. Did you mean 'datetime.now' instead of 'now'?
That should be just a bit clearer.
Pablo, what are your thoughts on this?
Reacted by Pablo Galindo Salgado, Nathan Goldbaum and Brian Schubert
Maybe we could just rephrase the error message? "Did you mean 'datetime.now' instead of 'now'"?
AttributeError: module 'datetime' has no attribute 'now'. Did you mean 'datetime.now' instead of 'now'?
I think rephrasing the message has the potential to be very helpful. Speaking just for myself, I'm not sure this particular message is a solution that would help me understand what's happening. The second sentence is still ambiguous about what datetime the message is talking about. As a reader I'd still think, "Yes, I did mean 'datetime.now', and that's what I wrote.'
I'm not sure on the style guide Python has for messages (I wasn't sure how to find this particular nuance), but would something like the following be acceptable?
AttributeError: module 'datetime' has no attribute '.now'. Did you mean '.datetime.now' instead of '.now'?
In text that explains code, I find that dots (.) at the start of attributes help contextualize the message and do a more effective job of orienting me when I'm trying to understand how pieces of architecture fit together. For me, the dots emphasize a very crucial part of the picture and tells me where those names would belong at-a-glance.
I apologize if this isn't an acceptable format in error messages, though. I suspect formatting of var names in error messages may belong in a broader discussion than this one issue.
Changing the first sentence is very unlikely.
It's much lower level. Plus, without suggestions, the message could be confusing to people used to the old format ('.now' is not a valid identifier nor attribute name).
Changing the second sentence is rather easy though, and it is not incorrect. I personally think it's an acceptable trade-off to only change the second sentence to the proposed format.
Changing the first sentence is very unlikely.
It's much lower level. Plus, without suggestions, the message could be confusing to people used to the old format ('.now' is not a valid identifier nor attribute name).
Changing the second sentence is rather easy though, and it is not incorrect. I personally think it's an acceptable trade-off to only change the second sentence to the proposed format.
Activity
johnslavik commentedon Jan 28, 2026
This suggestion comes from
traceback._check_nested_attribute.It probably won't. See @pablogsal's take on this in #137967 (comment).
Detecting the clash would require checking the scope for the name, too (locals, globals, etc).
Considering what Pablo said earlier, we'd likely want to avoid this either.
Maybe we could just rephrase the error message?
"Did you mean 'datetime.now' instead of 'now'"?That should be just a bit clearer.
Pablo, what are your thoughts on this?
pablogsal commentedon Jan 28, 2026
I think your suggestion makes it cleaner so I'm game!
plocket commentedon Jan 28, 2026
I think rephrasing the message has the potential to be very helpful. Speaking just for myself, I'm not sure this particular message is a solution that would help me understand what's happening. The second sentence is still ambiguous about what
datetimethe message is talking about. As a reader I'd still think, "Yes, I did mean 'datetime.now', and that's what I wrote.'I'm not sure on the style guide Python has for messages (I wasn't sure how to find this particular nuance), but would something like the following be acceptable?
In text that explains code, I find that dots (
.) at the start of attributes help contextualize the message and do a more effective job of orienting me when I'm trying to understand how pieces of architecture fit together. For me, the dots emphasize a very crucial part of the picture and tells me where those names would belong at-a-glance.I apologize if this isn't an acceptable format in error messages, though. I suspect formatting of var names in error messages may belong in a broader discussion than this one issue.
johnslavik commentedon Jan 29, 2026
Would you find this message equally understandable?
Changing the first sentence is very unlikely.
It's much lower level. Plus, without suggestions, the message could be confusing to people used to the old format (
'.now'is not a valid identifier nor attribute name).Changing the second sentence is rather easy though, and it is not incorrect. I personally think it's an acceptable trade-off to only change the second sentence to the proposed format.
@pablogsal?
pablogsal commentedon Feb 7, 2026
I think it's indeed more clear! Let's make this happen!
johnslavik commentedon Feb 8, 2026
Thanks for the dot proposal, @plocket. This makes the change much stronger.
gh-144285: Improve `AttributeError` attribute suggestions (#144299)
pythongh-144285: Improve `AttributeError` attribute suggestions (pyth…
gh-144285: Update *What's New* entry after GH-144299 (#145077)
pythongh-144285: Improve `AttributeError` attribute suggestions (pyth…
pythongh-144285: Update *What's New* entry after pythonGH-144299 (pyt…
pythongh-144285: Improve `AttributeError` attribute suggestions (pyth…
pythongh-144285: Update *What's New* entry after pythonGH-144299 (pyt…