3

The current number of milliseconds since the epoch is 1395245378429; on unix (64 bit / Ubuntu / python 2.7), you can do:

>>> t = 1395245378429
>>> type(t)
<type 'int'>
>>> t = 1395245378429L
>>> type(t)
<type 'long'>
>>> int(t)
1395245378429
>>> type(int(t)
<type 'int'>

but on Windows (also 64 bit / python 2.7), this happens:

>>> t = 1395245378429
>>> type(t)
<type 'long'>
>>> int(t)
1395245378429L
>>> type(int(t))
<type 'long'>

so, the following weird observations:

  • on Windows, int(<long>) returns a long
  • the same number is treated as a long in Windows, but an int on unix

I can't see anything obvious in the documentation to say this is correct behaviour; is there a (correct) way to convert the long to an int (i.e. so it can be used in a method which requires an int argument)

ChrisW
  • 4,970
  • 7
  • 55
  • 92
  • Get around *what*, exactly? What consequence of the int/long transition happening at a different value are you trying to avoid? – DSM Mar 19 '14 at 17:22
  • 2
    Note that even though you have 64-bit Windows you can still have a 32-bit Python installation, which seems to be the case here. – Scott Griffiths Mar 19 '14 at 17:28
  • Note that `int(20000000000000000000)` will return a `long` in both python 32 and 64 bit because that number is bigger than `2**64`. The conversion from `int` to `long` is almost always performed silently since, other then performance of operation, there shouldn't be any significant change in behaviour. I don't know of a situation that raises `OverflowError` between integer types. – Bakuriu Mar 19 '14 at 17:32

1 Answers1

6

Python uses C long for the int type, and even on Windows this is limited to 32-bit. You can see your platform's current maximum native int size by inspecting the sys.maxint value:

The largest positive integer supported by Python’s regular integer type. This is at least 2**31-1. The largest negative integer is -maxint-1 — the asymmetry results from the use of 2’s complement binary arithmetic.

and from the Numeric Types section:

Plain integers (also just called integers) are implemented using long in C, which gives them at least 32 bits of precision (sys.maxint is always set to the maximum plain integer value for the current platform, the minimum value is -sys.maxint - 1).

Unless you are directly interacting with a C extension library that doesn't support the Python long type, there is no need to worry about when Python uses int and when you need to use long. In Python 3, the separate long type has been removed entirely.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • Ah, ok - I was pretty sure I'd installed 64-bit python, obviously not! And this is the 1st time I'd ever come across a 32-/64-bit issue to find out... – ChrisW Mar 19 '14 at 17:32
  • Perhaps unfortunately (for me), I do seem to be using a C extension which doesn't accept longs, hence finding this issue – ChrisW Mar 19 '14 at 17:35
  • 1
    Python's internal representation of `` uses a C long type. Even on 64-bit Windows, Microsoft defines a C long to be 32 bits. So it won't matter if you use a 32 or 64-bit version of Windows. Most (all?) 64-bit Unix systems define a C long to be 64 bits. Speaking from personal experience, the difference in the definition of a C long causes lots of difficulties with C extensions. – casevh Mar 19 '14 at 18:14
  • 1
    @casevh: Ah, so this is perhaps a Windows issue after all. – Martijn Pieters Mar 19 '14 at 18:16
  • @ casevh : this has also caused me a lot of issues when trying to have a unified code across platforms to interface with C extensions. This may not help you if you don't want to depend on numpy but the workaround I have found is tu use the types numpy.int32 and numpy.int64 which are consistent across platforms. – YassineA Nov 16 '16 at 10:07