newb: Print ids, you get 1L, what is L?

[jobs]

When I execute the following sql,select id from people, inside python and print the result, I get this:

((11L,), (12L,), (13L,), (14L,), (15L,), (16L,), (17L,), (18L,), (19L,), (20L,))

Why does python print L beside the numbers. Just to indicate Long type?

[jrcagle]

Apparently so. You can check it:

>>> a =  ((11L,), (12L,), (13L,), (14L,), (15L,), (16L,), (17L,), (18L,), (19L,), (20L,))
>>> print a[0]
(11L,)
>>> print a[0][0]
11
>>> print type(a[0][0])
<type 'long'>
>>>

Jeff

[paddy3118]

If you are returning longs you can selectively turn them into integers using int() e.g:

>>> a =  ((11L,), (12L,), (13L,), (14L,), (15L,), (166666666666L,))
>>> b = tuple((int(i[0]),) for i in a)
>>> b
((11,), (12,), (13,), (14,), (15,), (166666666666L,))
>>>

- Paddy.

[timogoosen]

>>>399999999999999-399999999999998=
1L
>>>1L*0
0L

If you go to google, google's engine is written in python, and type in 399999999999999-399999999999998= it will give you the answer of 0(zero).
"A standard floating point number has roughly 16 decimal places of precision and a maximum value on the order of 10308, a 1 followed by 308 zeros. (According to IEEE standard 754, the typical floating point implementation.)
Sixteen decimal places is a lot. Hardly any measured quantity is known to anywhere near that much precision. For example, the constant in Newton's Law of Gravity is only known to four significant figures. The charge of an electron is known to 11 significant figures, much more precision than Newton's gravitational constant, but still less than a floating point number. So when are 16 figures not enough? One problem area is subtraction. The other elementary operations -- addition, multiplication, division -- are very accurate. As long as you don't overflow or underflow, these operations often produce results that are correct to the last bit. But subtraction can be anywhere from exact to completely inaccurate. If two numbers agree to n figures, you can lose up to n figures of precision in their subtraction. This problem can show up unexpectedly in the middle of other calculations."http://www.codinghorror.com/blog/2009/05/why-do-computers-suck-at-math/comments/page/2/

This also explains why 166666666666L cannot be converted to an int.