> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4