Take the 2-minute tour ×

Possible Duplicate:
accessing a python int literals methods

Everything in Python is an object. Even a number is an object:

>>> a=1
>>> type(a)
<class 'int'>

I tried the following, because we should be able to access class members of an object:

>>> type(1)
<class 'int'>
>>> 1.real
  File "<stdin>", line 1
SyntaxError: invalid syntax

Why does this not work?

share|improve this question

marked as duplicate by Martijn Pieters, mgilson, interjay, Bo Persson, Paul Hiemstra Oct 22 '12 at 17:24


it's a syntax error. the compiler doesn't understand the syntax. the language syntax (its grammar) is not defined so that you can type a method name after an integer. this is not an error when the program runs - it is from before the program runs. the parser cannot understand what you have typed. –  andrew cooke Aug 3 '12 at 19:46
@andrewcooke -- I think the question (beautifully demonstrated by the way) is why can't the parser handle this? You can access attributes/methods on literals of other types (consider the common "".join(...), why not integers? –  mgilson Aug 3 '12 at 19:48
it does indeed, but i thought that the main worry of the person asking the question was that somehow this meant that integers were not objects (see stackoverflow.com/questions/11801549/… from same user). hence my emphasis on how this is from a separate, earlier layer. –  andrew cooke Aug 3 '12 at 19:54

4 Answers 4

Although the behaviour with 1.real seems unlogical, it is expected due to the language specification: Python interprets 1. as a float (see floating point literals). But as @mutzmatron pointed out (1).real works because the expression in brackets is a valid Python object.

Update: Note the following pits:

1 + 2j.real
>>> 1.0      # due to the fact that 2j.real == 0
# but
1 + 2j.imag  
>>> 3.0      # due to the fact that 2j.imag == 2
share|improve this answer
1 + 2j.real only works by accident, it's equivalent to 1 + (2j.real), which is always equal to 1 + 0. –  Lauritz V. Thaulow Oct 22 '12 at 12:40
Thank you, for complementing @lazyr! –  BasicWolf Oct 22 '12 at 12:56

a language is usually built in three layers.

when you provide a program to a language it first has to "read" the program. then it builds what it has read into something it can work with. and finally it runs that thing as "a program" and (hopefully) prints a result.

the problem here is that the first part of python - the part that reads programs - is confused. it's confused because it's not clever enough to know the difference between




what seems to be happening is that it thinks you were trying to type a number like 1.234 but made a mistake and typed letters instead(!).

so this has nothing to do with what 1 "really is" and whether or not is it an object. all that kind of logic happens in the second and third stages i described earlier, when python tries to build and then run the program.

what you've uncovered is just a strange (but interesting!) wrinkle in how python reads programs.

[i'd call it a bug, but it's probably like this for a reason. it turns out that some things are hard for computers to read. python is probably designed so that it's easy (fast) for the computer to read programs. fixing this "bug" would probably make the part of python that reads programs slower or more complicated. so it's probably a trade-off.]

share|improve this answer
+1, and a link to Wikipedia's article on lexing, what that first step is commonly called. –  Izkata Aug 4 '12 at 3:40

Yes, an integer literal is an object in Python. To summarize, the parser needs to be able to understand it is dealing with an object of type integer, while the statement 1.real confuses the parser into thinking it has a float 1. followed by the word real, and therefore raises a syntax error.

To test this you can also try

>> (1).real

as well as,

>> 1.0.real

so in the case of 1.real python is interpreting the . as a decimal point.


BasicWolf puts it nicely too - 1. is being interpreted as the floating point representation of 1, so 1.real is equivalent to writing (1.)real - so with no attribute access operator i.e. period /full stop. Hence the syntax error.

Further edit

As mgilson alludes to in his/her comment: the parser can handle access to int's attributes and methods, but only as long the statement makes it clear that it is being given an int and not a float.

share|improve this answer
1 .real also works (and 1..real for the float). –  Josh Lee Aug 3 '12 at 19:41
The reason is that when Python sees some number of digits and then a period, it treats it as a decimal point and expects that it's a float. ETA: Right, you came to the same conclusion –  David Robinson Aug 3 '12 at 19:43
+1, but you might want to add a clear answer to the confusing title: Yes, an integer literal is an object; that's not the reason 1.real is failing. –  abarnert Aug 3 '12 at 20:21
@abarnert: Cheers, edit included. –  jmetz Aug 3 '12 at 20:24

You can still access 1.real:

>>> hasattr(1, 'real')
>>> getattr(1, 'real')
share|improve this answer
