Just filed 17992! http://bugs.python.org/issue17992 ----------------------------------------

Date: Wed, 15 May 2013 23:51:00 -0500 Subject: Re: [Python-Dev] [RELEASED] Python 2.7.5 From: benjamin@python.org To: carlosnepomuceno@outlook.com CC: python-dev@python.org

2013/5/15 Carlos Nepomuceno :

...

test_asynchat still hangs! What it does? Should I care?

Is there an issue filed for that?

-- Regards, Benjamin

On 5/16/2013 1:18 AM, Ben Hoyt wrote:

Thanks, Benjamin -- that's great!

This may not be a python-dev question exactly. But on Windows, is it safe to update to 2.7.5 on top of 2.7.4 (at C:\Python27) using the .msi installer? In other words, will it update/add/remove all the files correctly? What if python.exe is running?

Yes, I update all the time, but without python running.

...

Yes, I update all the time, but without python running.

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. -Ben

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

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

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. 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. Regards Antoine.

On 20/05/2013 12:47am, Pierre Rouleau wrote:

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.

Even in Python 2, if the result of arithmetic on ints which would overflow, the result automatically gets promoted to a long integer which is variable-length. >>> 2**128 340282366920938463463374607431768211456L >>> type(2), type(2**128) (, ) So the size of an int is pretty much irrelevant. -- Richard