14

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'>
>>>a.real
1

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
    1.real
         ^
SyntaxError: invalid syntax

Why does this not work?

Community
  • 1
  • 1
user1559873
  • 6,650
  • 8
  • 25
  • 28
  • 4
    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 03 '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 03 '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 http://stackoverflow.com/questions/11801549/python-data-types-are-classes-or-data-structures from same user). hence my emphasis on how this is from a separate, earlier layer. – andrew cooke Aug 03 '12 at 19:54

4 Answers4

19

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
  1

as well as,

>> 1.0.real
  1.0

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

Edit

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.

jmetz
  • 12,144
  • 3
  • 30
  • 41
  • 14
    `1 .real` also works (and `1..real` for the float). – Josh Lee Aug 03 '12 at 19:41
  • 6
    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 03 '12 at 19:43
  • 1
    +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 03 '12 at 20:21
  • @abarnert: Cheers, edit included. – jmetz Aug 03 '12 at 20:24
  • @JoshLee The fact that it actually works is itself *unreal*, considering of a developer used to a different programming language. – Galaxy Dec 27 '19 at 06:18
7

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
Zaur Nasibov
  • 22,280
  • 12
  • 56
  • 83
7

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 

1.234

and 

1.letters

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.]

andrew cooke
  • 45,717
  • 10
  • 93
  • 143
  • +1, and a link to Wikipedia's article on [lexing](http://en.wikipedia.org/wiki/Lexical_analysis), what that first step is commonly called. – Izkata Aug 04 '12 at 03:40
3

You can still access 1.real:

>>> hasattr(1, 'real')
True
>>> getattr(1, 'real')
1
RanRag
  • 48,359
  • 38
  • 114
  • 167
Brenden Brown
  • 3,125
  • 1
  • 14
  • 15