Suggestion for invalid decimal literal?

Python Help
1

from,

print(1.__add__)

    print(1.__add__)
           ^
SyntaxError: invalid decimal literal

to,

    print(1.__add__)
           ^
SyntaxError: invalid decimal literal, did you mean (1).__add__?

???

2 
a = 1
print(a.__add__)

I think, this is what you are looking for. (?)
Probably, interpreter is trying to read 1.__add__ as a float since you have a dot after an integer.

3

I meant changing the SyntaxError for invalid decimal literal
for example, (I ran it in Python 3.11)

import collections
collections.namedtoplo

gives,

AttributeError: module 'collections' has no attribute 'namedtoplo'. Did you mean: 'namedtuple'?

similarly for the above post, wouldn’t the error description be more detailed if there is a hint for addition of brackets?

2 Likes
4

That would definitely be pretty. But, why don’t you ask this in #ideas ? Most core developers doesn’t seem to look much at #users.

5

last time they moved my post from ideas to users.
so, posting it in users this time.

6

I think, worst thing they can do would be to say “That is hard to do.” or “We can not do that.” etc. . Improving syntax errors is a respected topic. -I have just looked at the issues page of cpython-

1 Like
7

I doubt very, very much, that this would be easily possible.

Python first reads the code as a series of “tokens”. Here, 1. is a token (FLOAT) and __add__ is a second token (‘NAME’). Afterwards, it uses the grammar rules to translate these tokens into an abstract syntax tree: it is at this stage that SyntaxErrors are identified. It has no way to recognize that one token (FLOAT) could actually be interpreted as two different tokens, so that 1.__add__ should be interpreted as 1 followed by the . operator, followed by __add__.

However, if you leave a space between 1 and the dot operator, you will not get a syntax error.

1 Like
8

why not suggest all possible / most common possible mistakes one could make in such a case, similar to,

if x = 1:
    print(‘true’)

SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?

so, in the above case, it could be something like,

SyntaxError: invalid decimal literal, did you intend to use an integer
instead of a float, maybe surround the integer by a (), or follow it with a space?

plus, for the == case, one possibility could also be, !=, which they did not include for some reason.
although it is a bit doubtful, as probably the user would be comparing equality, and if the user had to check for not equal then the user might write something more than a simple =, so maybe, the == or :=, instead of = is ok.

9

You have a float (1.) followed by a name (add). A valid expression (no syntax error) might simply require to add an operator like + or *, etc., between a float and a name. In fact, this is what is suggested by friendly in this situation.

Here, to get what you want, you simply need to insert a space, instead of surrounding by parentheses.

The point is that there are many possible “fixes” to the syntax error.

10

Raise a feature request on the bug tracker.

If it is simple enough to do, somebody will do it. If there are technical reasons why it can’t be done, someone there will say so.

It doesn’t need long debate or discussion about the API, or a PEP. It is in line with other improvements to the syntax errors. So just raise it on the bug tracker.

When you raise the issue, include a link back to this thread.

11

a similar case I see in one more place,
I did something like this,

pprint(dir(1), compact=True)

which gives me the error message,

NameError: name 'pprint' is not defined. Did you mean: 'print'?

but, here what actually is happening is that I did not write
from pprint import pprint, and attempted at using it, so, one other variation of the error message could have been,

NameError: name 'pprint' is not defined. 
Possible reasons for the error,
1) You meant: 'print'
2) You forgot to import pprint

where top 2-3 most common mistakes could be pointed out.

12

There’s only so much mind reading that the interpreter can do.

There is no limit to the number of things that you might have meant. It is not reasonable to expect the interpreter to search dozens of modules looking for near-misses and typos or forgotten imports.