[Python-Dev] Re: [Patches] PC\config.[hc] changes for Win64

[Trent Mick]

> Thanks, this makes more sense.  I guess that Trent's interest in Win64
> has to do with an early shipment of Itaniums that ActiveState might
> have received. :-)

Could be.... Or maybe we don't have any Itanium boxes. :)

Here is a good link on MSDN:

Getting Ready for 64-bit Windows
http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_410z.htm

More specifically this (presuming it is being kept up to date) documents the
changes to the Win32 API for 64-bit Windows:
http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_9xo3.htm
I am not a Windows programmer, but the changes are pretty minimal.

Summary:

Points for sys.platform == "win32" on Win64:
Pros:
- will not break existing sys.platform checks
- it would be nicer for casual Python programmer to have platform issues
  hidden, therefore one symbol for the common Windows OSes is more of the
  Pythonic ideal than "the first three characters of the platform string are
  'win'".
Cons:
- may need to add some other mechnism to differentiate Win32 and Win64 in
  Python code
- "win32" is a little misleading in that it refers to an API supported on
  Win32 and Win64 ("windows" would be more accurate, but too late for that)
  

Points for sys.platform == "win64" on Win64:
Pros:
- seems logically cleaner, given that the Win64 API may diverge from the
  Win32 API and there is no other current mechnism to differentiate Win32 and
  Win64 in Python code
Cons:
- may break existing sys.platform checks when run on Win64


Opinion:

I see the two choices ("win32" or "win64") as a trade off between:
- Use "win32" because a common user experience should translate to a common
  way to check for that environment, i.e. one value for sys.platform.
  Unfortunately we are stuck with "win32" instead of something like
  "windows".
- Use "win64" because it is not a big deal for the user to check for
  sys.platform[:3]=="win" and this way a mechanism exists to differentiate
  btwn Win32 and Win64 should it be necessary.

I am inclined to pick "win32" because:

1. While it may be confusing to the Python scriptor on Win64 that he has to
   check for win*32*, that is something that he will learn the first time. It
   is better than the alternative of the scriptor happily using "win64" and
   then that code not running on Win32 for no good reason. 
2. The main question is: is Win64 so much more like Win32 than different from
   it that the common-case general Python programmer should not ever have to
   make the differentiation in his Python code. Or, at least, enough so that
   such differentiation by the Python scriptor is rare enough that some other
   provided mechanism is sufficient (even preferable).
3. Guido has expressed that he favours this option. :) 

then change "win32" to "windows" in Py3K.



Trent

-- 
Trent Mick
trentm@activestate.com