| msg152827 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2012-02-08 01:57 |
| On the downloader page, http://www.python.org/download/releases/2.7.2/ there is an entry "•Windows X86-64 MSI Installer" that links to http://www.python.org/ftp/python/2.7.2/python-2.7.2.amd64.msi Running this installer succeeds and show messages that a 64-bit version of Python is being installed; however, running Python shows that only a 32-bit version is being run despite a welcome message stating that a 64-bit version is being run: C:\Python27>python Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 |
|
|
| msg152841 - (view) |
Author: Nadeem Vawda (nadeem.vawda) * |
Date: 2012-02-08 09:22 |
| 64-bit Windows (or at least Visual C++) uses the LLP64 model, so a long is 32 bits wide (the only 64-bit integer type being long long) - see <http://en.wikipedia.org/wiki/64-bit#64-bit_data_models> Since Python's int is documented as being implemented on top of C's long, this behaviour appears to be correct (if surprising). |
|
|
| msg152844 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2012-02-08 11:26 |
| IIRC sys.maxsize was added for this reason. This one should show a 64bit value. |
|
|
| msg152848 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2012-02-08 12:49 |
| struct.calcsize("P")==8 will tell you if you're running a 64bit python or not. |
|
|
| msg152850 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2012-02-08 12:51 |
| Or more directly, try platform.architecture(). |
|
|
| msg152854 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2012-02-08 12:58 |
| according to the documentation platform.architecture() may not work on OS X. |
|
|
| msg152906 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2012-02-08 20:24 |
| platform.architecture() and struct.calcsize("P") confirm that this build used 64-bits for pointers and 32-bits for ints. This leaves the question of whether LLP64 is required to run Python on Windows or whether another memory model could have been selected during compilation (IOW, do we have to live with 32-bit ints on Windows)? |
|
|
| msg152907 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2012-02-08 20:33 |
| LLP64 is the model chosen by the Microsoft compiler: sizeof(long)==4. I suppose someone already considered to change PyIntObject and use size_t values, but IMO it would have broken too many extensions: the pattern "if (PyInt_Check(obj)) value=PyInt_AS_LONG(obj);" is very very common. |
|
|
| msg152910 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-02-08 21:08 |
| On Win64, the long type is 32-bit; the compiler does not support any other mode. So the question "whether another memory model could have been selected during compilation" must be answered as "no, the compiler does not support multiple memory models". We could have chosen to not use long for ob_ival. However, that would have cause a massive API change, as functions such as PyLong_AsLong either would have to change their return type, or start raising exceptions even for exact int objects. In Python 3, this issue is fixed as the int type has no range constraint anymore. |
|
|
| msg152981 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2012-02-09 20:21 |
| Martin, thanks for the explanation. Hopefully, this tracker entry will serve to permanently document why Python2 on Windows behaves as it does. |
|
|