Marc-Andre Lemburg <m...@egenix.com> added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis <mar...@v.loewis.de> added the comment:
>
>> The change to sys.platform=='linux' would break code even on current
>> platforms.
>
> Correct. Compared to introducing 'linux3', I consider this the better
> change - it likely breaks earlier (i.e. when porting to Python 3.3).
>
>> OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
>> favor keeping 'linux2' on all versions of Linux as well?
>
> While this has better compatibility, it's also a constant source of
> irritation. Introducing 'win64' would have been a worse choice (just
> as introducing 'linux3' would: incompatibility for no gain, since
> the distinction between win32 and win64, from a Python POV, is
> irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
> rather wants people to refer to the "Windows API".
>
> I personally disliked 'linux2' when it was introduced, for its
> incompatibilities. Anticipating that, some day, we may have 'Linux 4',
> and so on, I still claim it is better to fix this now. We could even
> come up with a 2to3 fixer for people who dual-source their code.
I think we should consider adding a better mechanism and just
keep the old mechanism for determining sys.platform in place
(letting it break on Linux to raise awareness) and add a new better
attribute along the lines of what Martin suggested:
sys.system == 'linux', 'freebsd', 'openbsd', 'windows', etc.
(without version)
and a new
sys.system_info == system release info (named) tuple similar to
sys.version_info
to query a specific system version.
As already noted, direct sys.platform testing already breaks for
OpenBSD, FreeBSD and probably a few other OSes as well with
every major OS release, so the Linux breakage is not really new
in any way.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
