Issue 5778: sys.version format differs between MSC and GCC (original) (raw)

Issue5778

Created on 2009-04-17 09:00 by t-kamiya, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg86060 - (view)	Author: Toshihiro Kamiya (t-kamiya)	Date: 2009-04-17 09:00
The value of sys.version includes a new-line char in GCC build. '2.5.2 (r252:60911, Oct 5 2008, 19:24:49) \n[GCC 4.3.2]' MSC build doesn't. '2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit (AMD64)]' This seems a kind of pitfall for the developers who use this variable.
msg109684 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2010-07-09 05:19
msc is the same in 3.1. How about gcc? If still different, what change are you proposing? add \n to one or delete it from other? I agree that this is a (minor) unfortunate difference, but ... Changing either would be a pitfall to developers who only use one or the other and have adapted to what they get. Those on both have probably learned to work with the difference. However, unless they do something like sys.version.strip(), they might have code invalidated too. Of course, future developers might benefit.
msg112183 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-07-31 19:23
This change would bring the code in agreement with the docs: 'version (#build_number, build_date, build_time) [compiler]'. FWIW, it would also save one line, which can be useful in small terminals/consoles. Tentatively adding the easy keyword since fixing Python/getversion.c would probably not take much time for a C programmer.
msg112185 - (view)	Author: Georg Brandl (georg.brandl) *	Date: 2010-07-31 19:32
Hmm, in Python/getcompiler.c there is an explicit \n before [GCC ...], and this is why: ------------------------------------------------------------------------ r17259 | gvanrossum	2000-09-05 06:40:39 +0200 (Di, 05. Sep 2000) The GCC version is loooooooooong; put it on a new line. ------------------------------------------------------------------------
msg112187 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-07-31 19:37
Maybe it has changed in ten years: [GCC 4.4.4] on linux2 Or maybe it’s looooong when run from an unreleased version built from the sources.
msg112191 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2010-07-31 19:53
On OS X, it's still something like 2.6.5 (r265:79359, Mar 24 2010, 01:32:55) [GCC 4.0.1 (Apple Inc. build 5493)] on Redhat, it once was 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] Apple once had 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] I also found 2.2.2 (#0, Mar 23 2007, 12:02:04) [GCC 2.9-psion-98r2 (Symbian build 546)] 2.4.4 (#2, Apr 5 2007, 20:11:18) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] Python 2.2.2 (#1, Oct 28 2002, 17:22:19) [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] I recommend to close this as "won't fix". There is no promise that sys.version follows any particular syntax. Developers should use sys.version_info instead, and the platform module (e.g. platform.python_compiler())
msg112193 - (view)	Author: Georg Brandl (georg.brandl) *	Date: 2010-07-31 20:00
Agreed. I've also added a sentence in the docs (r83357) that a newline may be present.
msg112196 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2010-07-31 20:29
Fair enough, I’d hate to cause the line to wrap over 80 characters for other people, so I’d live with the extra line on my system Pythons and with a personal patch for the versions I compile myself :) Thank you both for the thoughts and the fix.