Re: [Python-Dev] [RELEASED] Python 2.7.5
Hi all, I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer. When I evaluate sys.maxint I don't get what I was expected. I get this: Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import sys >>> sys.maxint 2147483647 >>> import platform >>> platform.machine() 'AMD64' >>> import os >>> os.environ['PROCESSOR_ARCHITECTURE'] 'AMD64' >>> Should I not get a 64-bit integer maxint (9223372036854775807) for sys.maxint ? Or is there something I am missing here? Thanks! / Pierre Rouleau On Thu, May 16, 2013 at 6:23 AM, "Martin v. Löwis" wrote: > Am 16.05.13 10:42, schrieb Ben Hoyt: > > > FYI, I tried this just now with Python 2.7.4 running, and the > > installer nicely tells you that "some files that need to be updated > > are currently in use ... the following applications are using files, > > please close them and click Retry ... python.exe (Process Id: 5388)". > > > > So you can't do it while python.exe is running, but at least it > > notifies you and gives you the option to retry. Good work, whoever did > > this installer. > > This specific feature is part of the MSI technology itself, so the honor > goes to Microsoft in this case. They also have an advanced feature where > the installer can tell the running application to terminate, and then > restart after installation (since Vista, IIRC). Unfortunately, this > doesn't apply to Python, as a "safe restart" is typically not feasible. > > FWIW, I'm the one who put together the Python installer. > > Regards, > Martin > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/prouleau001%40gmail.com > -- /Pierre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7.5
OK thanks, Benjamin, you are correct sys.maxsize is 2*63-1 on it. I was under the impression that Python was using int_64_t for the implementation of Win64 based integers. Most probably because I've sen discussion on Python 64 bits and those post were most probably were in the scope of some Unix-type platform. Regards, On Sun, May 19, 2013 at 6:56 PM, Benjamin Peterson wrote: > 2013/5/19 Pierre Rouleau : > > Hi all, > > > > I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS > computer. > > When I evaluate sys.maxint I don't get what I was expected. I get this: > > > > Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit > (AMD64)] on > > win32 > > Type "copyright", "credits" or "license()" for more information. > >>>> import sys > >>>> sys.maxint > > 2147483647 > >>>> import platform > >>>> platform.machine() > > 'AMD64' > >>>> import os > >>>> os.environ['PROCESSOR_ARCHITECTURE'] > > 'AMD64' > >>>> > > > > > > Should I not get a 64-bit integer maxint (9223372036854775807) for > > sys.maxint ? > > This is correct. sizeof(long) != sizeof(void *) on Win64, and size > Python int's are platform longs, you get the maxsize of a 32-bit int. > Check sys.maxsize for comparison. > > > > -- > Regards, > Benjamin > -- /Pierre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7.5
On that topic of bitness for 64-bit platforms, would it not be better for CPython to be written such that it uses the same 64-bit strategy on all 64-bit platforms, regardless of the OS? As it is now, Python running on 64-bit Windows behaves differently (in terms of bits for the Python's integer) than it is behaving in other platforms. I assume that the Python C code is using the type 'long' instead of something like the C99 int64_t. Since Microsoft is using the LLP64 model and everyone else is using the LP64, code using the C 'long' type would mean something different on Windows than Unix-like platforms. Isn't that unfortunate? Would it not be better to hide the difference at Python level? Or is it done this way to allow existing C extension modules to work the way they were and request Python code that depends on integer sizes to check sys.maxint? Also, I would imagine that the performance delta between a Windows 32-bit Python versus 64-bit Python is not as big as it would be on a Unix computer. As far as I can se Python-64 bits on Windows 64-bit OS has a larger address space and probably does not benefit from anything else. Has anyone have data on this? Thanks -- /Pierre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7.5
On Sun, May 19, 2013 at 7:41 PM, Antoine Pitrou wrote: > On Sun, 19 May 2013 19:37:46 -0400 > Pierre Rouleau wrote: > > > On that topic of bitness for 64-bit platforms, would it not be better for > > CPython to be written such that it uses the same 64-bit strategy on all > > 64-bit platforms, regardless of the OS? > > > > As it is now, Python running on 64-bit Windows behaves differently (in > > terms of bits for the Python's integer) than it is behaving in other > > platforms. I assume that the Python C code is using the type 'long' > > instead of something like the C99 int64_t. Since Microsoft is using the > > LLP64 model and everyone else is using the LP64, code using the C 'long' > > type would mean something different on Windows than Unix-like platforms. > > Isn't that unfortunate? > > Well, it's Microsoft's choice. But from a Python point of view, which C > type a Python int maps to is of little relevance. > Fair > > Moreover, the development version is 3.4, and in Python 3 the int > type is a variable-length integer type (sys.maxint doesn't exist > anymore). So this discussion is largely moot now. > > Good to know. Too bad there still are libraries not supporting Python 3. Thanks. > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/prouleau001%40gmail.com > -- /Pierre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
