Long integers: to L or not to L?

[Dimitris Garanatsios]

Tetsuo wrote:
> I have a function that uses longs, and also of the length of their
> equivalent strings. I thought that longs have an L at the end, so I
> suntracted 2 instead of 1 from the length. The program gave wrong
> results. I put print statements in. The value returned by function
> long(n) was a plain integer, with no L. I checked the type of that
> return value. Long. So why no L?

I don't really understand the situation you are in... :-(
But, about this mysterious "L" you are talking about:
Long integers are numbers just like simple integers that need more 
memory to be stored and are capable of representing large numbers. 
Recent versions of python automatically take care of this by converting 
to Long integers any large number that cannot be represented by a plain 
integer:

 >>> type(1)
<type 'int'>

type(1000000000000)
<type 'long'>

If you really want to explicitly use Long integers in your function, you 
denote that using an "L" after the number you want (this is a special 
syntax for Long integers):

 >>> type(1L)
<type 'long'>

This "L" is not part of the number ofcourse... See this:

 >>> i = 1L # equivalent to i = long(1)
 >>> type(i)
<type 'long'>
 >>> print i
1
 >>> print str(i)
1
 >>> print repr(i)
1L

What happens here is this:
I have stored a Long integer in variable i. This object is a python 
builtin type that has a __str__ and __repr__ special methods (consult 
python's documentation about these two). When you use print or call the 
str() builtin function, the number is converted to a string object using 
it's __str__ special method. The builtin function repr() though, calls 
its __repr__ special method instead, resulting in a more detailed but 
less "user-friendly" result (afterall, when you want your program to 
print a number you want it to show what number this is, not it's type or 
any irrelevant info).

> 
> Also, why does this raise an error? (numbers in front of lines indicate
> levels of indentation)
> 
>  def h():
> 1     i = 0
> 1     def h1():
> 3         i = i + 1
> 3         print 1, i
> 3        if i == 5:
> 4             return i
> 3         else:
> 4             i = h1()
> 4             return i
> 1    i = h1()
> 1    print 2, i
> 
> Posting code is annoying...
> 
> --
> Posted via http://dbforums.com

Well, actually it doesn't raise any kind of an error (by itself...). I 
assume that you are running this inside an IDE (most propably the 
excellent PythonWin) which for some reason fails to parse this (i get an 
IndentationError too when i run this the first time in PythonWin which 
"disappears" the second time!).

Don't trust IDEs when you are about to run the script you just edited. 
If you save the above example in a file and run it from the console with

python myscript.py

no error gets raised...
...but if you ever call function h() you might get:

Traceback (most recent call last):
   File "script1.py", line 14, in ?
     h()
   File "script1.py", line 11, in h
     i = h1()
   File "script1.py", line 4, in h1
     i = i + 1
UnboundLocalError: local variable 'i' referenced before assignment

This is because nested scopes in python is a new addition which is not 
supported in my version (2.2.1) unless a "from __future__ import ..." is 
used. So in this case the "i = 0" statement is not seen inside h1(). 
Again, you may consult python's documentation for more details about new 
feature additions...

Another pitfall when using IDEs to test a script is that it will run it 
(at least PythonWin will) in the same environment with it's own 
interpreter. This is bad for example if you have imported a module in 
this interpreter and use it in your script but forgot to import it 
there. Running it in the IDE's interpreter no error will ever be raised, 
but in a "clean" environment you'll never get it run...

Regards,
Dimitris