Repository navigation
Add cross-language method suggestions for builtin AttributeError #146406
Description
Proposal
When an AttributeError occurs on a builtin type (list, str, dict) and the existing Levenshtein-based suggestion system finds no match, check a static table of common method names from other programming languages.
Before:
>>> [1, 2, 3].push(4)
AttributeError: 'list' object has no attribute 'push'After:
>>> [1, 2, 3].push(4)
AttributeError: 'list' object has no attribute 'push'. Did you mean '.append' instead of '.push'?Discourse discussion
This was discussed at https://discuss.python.org/t/cross-language-method-suggestions-for-attributeerror/106632 (420 views, 25 likes, 3 core devs participated).
Design decisions from the discussion:
-
Flat table approach per @pf_moore (post 14, 4 likes): each (type, attr) entry carries the exact suggestion text. No runtime introspection of related types needed.
-
list.add() suggests using a set per @Storchaka (post 8) and @tjreedy (post 12): "It can also mean that you passed a list instead of set." The table maps this to a wrong-type hint rather than suggesting append.
-
Option 1: static table for builtins only - community consensus. 11 entries covering JS/Java/C#/Ruby. Inclusion criteria: evidence of real confusion, not catchable by Levenshtein, from a top-4 language.
-
Scope guardrails per @dr_carlos (post 3): "only add entries with clear evidence of real confusion, not just because two methods do similar things."
Examples
| What user writes | Before | After |
|---|---|---|
| [].push(4) | no suggestion | Did you mean '.append'? |
| "".toUpperCase() | no suggestion | Did you mean '.upper'? |
| {}.keySet() | no suggestion | Did you mean '.keys'? |
| [].add(1) | no suggestion | Did you mean to use a set? |
| "".trimStart() | no suggestion | Did you mean '.lstrip'? |
Entries where Levenshtein already provides a match (indexOf->index, trim->strip) are intentionally excluded from the table since they already work.
Implementation
~60 lines in Lib/traceback.py: a dict mapping (builtin_type, wrong_name) to suggestion text, a small lookup function, and a 4-line hook in TracebackException.__init__ that runs only when Levenshtein found nothing. Tests cover all entries plus priority ordering and subclass exclusion.
Has this already been discussed elsewhere?
Yes, on Discourse: https://discuss.python.org/t/106632
Activity
picnixz commented on Mar 25, 2026
Can you link the old issue to that one for cross references please?
serhiy-storchaka commented on Mar 26, 2026
The proposed code only works for instances of the base classes. It does not work for OrderedDict, for example. So, instead of dict lookup by type you need to iterate the table and use isinstance(). You can also do a lookup by the method name, and then iterate possible types.
The most common error is when you get None instead of the expected type. I suggest to add a separate table for often used methods of builtin types and suggest the most likely candidates. Note that "update" is the method of dict and set.
Other common error is using the mutating method for immutable object, like "append" for tuple.
int, float and complex also can be mixed.
picnixz commented on Mar 26, 2026
I thought about it as well and was about to suggest this as a follow-up where we have finer-grained alternatives but I was still mulling over a good design.
I think, the problem comes at runtime rather when objects are passed through. For instance, you start with an int and somewhere in your code, that int becomes a float and then you have some code doing value.<int-method> and get an exception here. Telling you that it's the wrong method won't necessarily help you; what could have helped you is to know when the int became a float but it's not possible to track that except through linters.
OTOH, the issue was especially focused on cross-language issues; In JS, for instance, the methods involved in the numeric tower that you could have incorrectly used are probably:
However, the two first are unlikely to be suggested because you'll likely write Number.* in Python and you get a NameError because of Number not existing instead of writing int.*. So I don't know if it makes sense to suggset them. Only methods that can be present on instances in both languages will be caught by this new feature. We could add a suggestion for the int type itself though but the current design with isinstance or __class__ checks wouldn't work exactly unless we also encode the fact that it's a class method
Sorry if I missed an obvious case about "mixing" the numeric types. Did you have a concrete example in mind?
serhiy-storchaka commented on Mar 26, 2026
As in case of list.add, the error message should point on possible wrong type error. It should not suggest unrelated method.
For example:
I think we can provide better error message.
picnixz commented on Mar 26, 2026
Ah I see. Yes, fixing message suggestions like that seems reasonable indeed.
gh-146406: Add cross-language method suggestions for builtin Attribut…
gh-146406: add clear() cross-language hint for immutable types (GH-14…