When reporting issue to some project and want to include python version in the report, python -V shows very limited information.
$ ./python.exe -V Python 3.6.0b2+
sys.version is more usable, but it requires one liner.
$ ./python.exe -c 'import sys; print(sys.version)' 3.6.0b2+ (3.6:86a1905ea28d+, Oct 13 2016, 17:58:37) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
How about `python -vV` shows sys.version?
perl -V is very verbose and it's helpful to be included in bug report. Some of them are useful and worth enough to include in `python -vV`.
$ perl -V Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
Platform: osname=darwin, osvers=15.0, archname=darwin-thread-multi-2level uname='darwin osx219.apple.com 15.0 darwin kernel version 15.0.0: fri may 22 22:03:51 pdt 2015; root:xnu-3216.0.0.1.11~1development_x86_64 x86_64 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=cc' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-arch i386 -arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector' ccversion='', gccversion='4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc -mmacosx-version-min=10.11.3', ldflags ='-arch i386 -arch x86_64 -fstack-protector' libpth=/usr/lib /usr/local/lib libs= perllibs= libc=, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch i386 -arch x86_64 -bundle -undefined dynamic_lookup -fstack-protector'
Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Locally applied patches: /Library/Perl/Updates/<version> comes before system perl directories installprivlib and installarchlib points to the Updates directory Built under darwin Compiled at Aug 11 2015 04:22:26 @INC: /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .
For all intents and purposes other than debugging C (for cpython, rpython for pypy, java for jython, .NET for IronPython... you get the idea), the extra details are unnecessary to debug most problems. Most of the time it is sufficient to know what major, minor, and patchlevel you are using. You only really need to know the commit hash and compiler if you are sending a bug report about the C... and since you know when you are doing that... I don't think its uncalled for to have the one liner.
-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@python.org] On Behalf Of INADA Naoki Sent: Friday, October 14, 2016 3:40 AM To: python-ideas python-ideas@python.org Subject: [Python-ideas] Show more info when `python -vV`
When reporting issue to some project and want to include python version in the report, python -V shows very limited information.
$ ./python.exe -V Python 3.6.0b2+
sys.version is more usable, but it requires one liner.
$ ./python.exe -c 'import sys; print(sys.version)' 3.6.0b2+ (3.6:86a1905ea28d+, Oct 13 2016, 17:58:37) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
How about `python -vV` shows sys.version?
perl -V is very verbose and it's helpful to be included in bug report. Some of them are useful and worth enough to include in `python -vV`.
$ perl -V Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
Platform: osname=darwin, osvers=15.0, archname=darwin-thread-multi-2level uname='darwin osx219.apple.com 15.0 darwin kernel version 15.0.0: fri may 22 22:03:51 pdt 2015; root:xnu-3216.0.0.1.11~1development_x86_64 x86_64 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=cc' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-arch i386 -arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector' ccversion='', gccversion='4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc -mmacosx-version-min=10.11.3', ldflags ='-arch i386 -arch x86_64 -fstack-protector' libpth=/usr/lib /usr/local/lib libs= perllibs= libc=, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch i386 -arch x86_64 -bundle -undefined dynamic_lookup -fstack-protector'
Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND
USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_APILocally applied patches: /Library/Perl/Updates/<version> comes before system perl directories installprivlib and installarchlib points to the Updates directory Built under darwin Compiled at Aug 11 2015 04:22:26 @INC: /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .
-- INADA Naoki songofacandy@gmail.com _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Oct 14, 2016 at 9:09 AM, tritium-list@sdamon.com wrote:
For all intents and purposes other than debugging C (for cpython, rpython for pypy, java for jython, .NET for IronPython... you get the idea), the extra details are unnecessary to debug most problems. Most of the time it is sufficient to know what major, minor, and patchlevel you are using. You only really need to know the commit hash and compiler if you are sending a bug report about the C... and since you know when you are doing that... I don't think its uncalled for to have the one liner.
The compiler information generally reveals the OS as well (if only accidentally), and the OS is often useful information.
-n
Nathaniel Smith njs@pobox.com wrote:
The compiler information generally reveals the OS as well (if only accidentally), and the OS is often useful information.
But in which situation would you really need to call Python from outside to find out which OS you're on?
Sebastian
On Sat, Oct 15, 2016 at 4:52 AM, Sebastian Krause sebastian@realpath.org wrote:
Nathaniel Smith njs@pobox.com wrote:
The compiler information generally reveals the OS as well (if only accidentally), and the OS is often useful information.
But in which situation would you really need to call Python from outside to find out which OS you're on?
It's an easy way to gather info. Example:
rosuav@sikorsky:~$ python3 -Wall Python 3.7.0a0 (default:897fe8fa14b5+, Oct 15 2016, 03:27:56) [GCC 6.1.1 20160802] on linux Type "help", "copyright", "credits" or "license" for more information.
"C:\Users\Demo"
File "<stdin>", line 1 SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape
"C:\Documents\Demo"
sys:1: DeprecationWarning: invalid escape sequence '\D' sys:1: DeprecationWarning: invalid escape sequence '\D' 'C:\Documents\Demo'
Just by copying and pasting the header, I tell every reader what kind of system I'm running this on. Sure, I could tell you that I'm running Debian Stretch, and I could tell you that I've compiled Python from tip, but the header says all that and in a way that is permanently valid.
ChrisA
On 15 October 2016 at 03:52, Sebastian Krause sebastian@realpath.org wrote:
Nathaniel Smith njs@pobox.com wrote:
The compiler information generally reveals the OS as well (if only accidentally), and the OS is often useful information.
But in which situation would you really need to call Python from outside to find out which OS you're on?
Folks don't always realise that the nominal version reported by redistributors isn't necessarily exactly the same as the upstream release bearing that version number. This discrepancy is most obvious with LTS Linux releases that don't automatically rebase their supported Python builds to new maintenance releases, and instead selectively backport changes that they or their customers need.
This means that it isn't always sufficient to know that someone is running "Python on CentOS 6" (for example) - we sometimes need to know which *build* of Python they're running, as if a problem can't be reproduced with a recent from-source upstream build, it may be due to redistributor specific patches, or it may just be that there's an already implemented fix upstream that the redistributor hasn' t backported yet.
So +1 from me for making "python -vV" a shorthand for "python -c 'import sys; print(sys.version)'". Since older versions won't support it, it won't help much in the near term (except as a reminder to ask for "sys.version" in cases where it may be relevant), but it should become a useful support helper given sufficient time.
Cheers, Nick.
On 14.10.16 10:40, INADA Naoki wrote:
When reporting issue to some project and want to include python version in the report, python -V shows very limited information.
$ ./python.exe -V Python 3.6.0b2+
sys.version is more usable, but it requires one liner.
$ ./python.exe -c 'import sys; print(sys.version)' 3.6.0b2+ (3.6:86a1905ea28d+, Oct 13 2016, 17:58:37) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
How about `python -vV` shows sys.version?
Are there precedences of combining verbose and version options in other programs?
PyPy just outputs sys.version for the --version option.
$ pypy -V Python 2.7.10 (5.4.1+dfsg-1~ppa1~ubuntu16.04, Sep 06 2016, 23:11:39) [PyPy 5.4.1 with GCC 5.4.0 20160609]
I think it would not be large breakage if new releases of CPython become outputting extended version information by default.
Are there precedences of combining verbose and version options in other programs?
No, I was just afraid about other programs rely on format of python -V.
PyPy just outputs sys.version for the --version option.
$ pypy -V Python 2.7.10 (5.4.1+dfsg-1~ppa1~ubuntu16.04, Sep 06 2016, 23:11:39) [PyPy 5.4.1 with GCC 5.4.0 20160609]
I think it would not be large breakage if new releases of CPython become outputting extended version information by default.
I like it if it's OK. Does anyone against this?
On 16 October 2016 at 04:36, INADA Naoki songofacandy@gmail.com wrote: [Serhiy wrote]
Are there precedences of combining verbose and version options in other programs?
No, I was just afraid about other programs rely on format of python -V.
That would be my concern as well - while I can't *name* any specific projects that use "python -V" to extract version info (e.g. for filename generation based on MAJOR.MINOR), it's still the obvious thing to call if you need that info and aren't already writing in Python yourself.
I think it would not be large breakage if new releases of CPython become outputting extended version information by default.
I like it if it's OK. Does anyone against this?
I think adding "verbose version" is a good idea, with a clear and reasonably obvious meaning.
While it *is* a little unusual to implement it that way, I don't think that's sufficient reason to break with the established output format for the plain "-V".
Cheers, Nick.
On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan ncoghlan@gmail.com wrote:
While it *is* a little unusual to implement it that way, I don't think that's sufficient reason to break with the established output format for the plain "-V".
Seems reasonable. Minor point: I'd be forever having to check whether it's -vV, -Vv, or -VV - particularly as I often find myself using "python -v", and groaning at the spew of spam as interactive Python starts up in verbose mode. Can all three be added, maybe? Then -Vv and -vV are "verbose version", and -VV is "version, and more so" (in the same way that -qq is more quiet than q, or -gg is more debuggy than -g).
ChrisA
On 17 October 2016 at 13:40, Chris Angelico rosuav@gmail.com wrote:
On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan ncoghlan@gmail.com wrote:
While it *is* a little unusual to implement it that way, I don't think that's sufficient reason to break with the established output format for the plain "-V".
Seems reasonable. Minor point: I'd be forever having to check whether it's -vV, -Vv, or -VV
If we use the normal verbose flag, then both "-vV" and "-Vv" will work, since options can be provided in any order.
I don't think it makes sense to also allow "-VV" - we're not requesting the version twice, we're asking for more verbose version information. Since "-v" is already a counted option, we're also free to expand it to give even more info the more verbose we ask it to be (although initially I think pursuing just Inada-san's main suggestion of matching the REPL header makes sense)
Cheers, Nick.
On Mon, Oct 17, 2016 at 3:21 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 17 October 2016 at 13:40, Chris Angelico rosuav@gmail.com wrote:
On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan ncoghlan@gmail.com wrote:
While it *is* a little unusual to implement it that way, I don't think that's sufficient reason to break with the established output format for the plain "-V".
Seems reasonable. Minor point: I'd be forever having to check whether it's -vV, -Vv, or -VV
If we use the normal verbose flag, then both "-vV" and "-Vv" will work, since options can be provided in any order.
That's a good start, at least.
I don't think it makes sense to also allow "-VV" - we're not requesting the version twice, we're asking for more verbose version information.
It's not as far-fetched as you might think - if "vv" means "more verbose", and "qq" means "more quiet", then "VV" means "more version info". It's a form of word doubling for emphasis, a tradition that dates back at least as far as ancient Hebrew, and has some currency in English. And if -VV has no other meaning, it's not going to hurt to accept it as an alias for -Vv, right? Remember, this option isn't only for the expert - it's also for the novice, who might be typing at the dictation of someone else ("can you tell me what python -vV says, please? -- no, that's one capital V and one small v -- no no, not both capital, just one"). But if it can't be done, so be it. At least with them being independent flags, the order doesn't matter.
Since "-v" is already a counted option, we're also free to expand it to give even more info the more verbose we ask it to be (although initially I think pursuing just Inada-san's main suggestion of matching the REPL header makes sense)
Sure, I guess. Not sure what -Vvv would mean, but okay. The same could easily be done with -VVV though, just by making -V a counted option. Logic could simply be:
if Version: # Count verbosity based on -v and/or -V Version += verbose if Version >= 3: print("info for -Vvv") if Version >= 2: print(sys.version) if Version == 1: # subsumed into the above print(sys.version.split(" ")[0])
ChrisA
Since "-v" is already a counted option, we're also free to expand it to give even more info the more verbose we ask it to be (although initially I think pursuing just Inada-san's main suggestion of matching the REPL header makes sense)
Sure, I guess. Not sure what -Vvv would mean, but okay. The same could easily be done with -VVV though, just by making -V a counted option. Logic could simply be:
Fortunately, it's a counting option already. In Modules/main.c:
case 'v': Py_VerboseFlag++; break; ... case 'V': version++; break; ... if (version) { printf("Python %s\n", PY_VERSION); return 0; }
So change is easy:
diff -r 0b29adb5c804 Modules/main.c --- a/Modules/main.c Mon Oct 17 06:14:48 2016 +0300 +++ b/Modules/main.c Mon Oct 17 15:00:26 2016 +0900 @@ -512,7 +512,12 @@ Py_Main(int argc, wchar_t **argv) return usage(0, argv[0]);
if (version) { - printf("Python %s\n", PY_VERSION); + if (version >= 2) { // or if (version >= 2 || Py_VerboseFlag) { + printf("Python %s\n", Py_GetVersion()); + } + else { + printf("Python %s\n", PY_VERSION); + } return 0; }
$ ./python.exe -V Python 3.6.0b2+
$ ./python.exe -VV Python 3.6.0b2+ (3.6:0b29adb5c804+, Oct 17 2016, 15:00:12) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
$ ./python.exe -VVV Python 3.6.0b2+ (3.6:0b29adb5c804+, Oct 17 2016, 15:00:12) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
On Mon, Oct 17, 2016 at 5:02 PM, INADA Naoki songofacandy@gmail.com wrote:
$ ./python.exe -V Python 3.6.0b2+
$ ./python.exe -VV Python 3.6.0b2+ (3.6:0b29adb5c804+, Oct 17 2016, 15:00:12) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
LGTM.
What's the view on backporting this to 2.7.x? We're still a good few years away from its death, and it'd be helpful if recent 2.7s could give this info too.
ChrisA
(Added python-dev in CC list, because there are enough +1 already).
On Mon, Oct 17, 2016 at 3:06 PM, Chris Angelico rosuav@gmail.com wrote:
On Mon, Oct 17, 2016 at 5:02 PM, INADA Naoki songofacandy@gmail.com wrote:
$ ./python.exe -V Python 3.6.0b2+
$ ./python.exe -VV Python 3.6.0b2+ (3.6:0b29adb5c804+, Oct 17 2016, 15:00:12) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]
LGTM.
What's the view on backporting this to 2.7.x? We're still a good few years away from its death, and it'd be helpful if recent 2.7s could give this info too.
ChrisA
I want to add it at least Python 3.6. Because one reason I want to propose this is I can't see exact Python version (commit id) for "nightly" or "3.6-dev" on Travis-CI test.
But Python 3.6 is beta stage already. If we apply rule strictly, it should be added only in default branch (Python 3.7).
So, what version can I add this?
a. Only Python 3.7+ b. (beta) Python 3.6+ c. (maintenance) Python 2.7 and Python 3.5+
On 17 October 2016 at 15:51, Chris Angelico rosuav@gmail.com wrote:
On Mon, Oct 17, 2016 at 3:21 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 17 October 2016 at 13:40, Chris Angelico rosuav@gmail.com wrote:
On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan ncoghlan@gmail.com wrote:
While it *is* a little unusual to implement it that way, I don't think that's sufficient reason to break with the established output format for the plain "-V".
Seems reasonable. Minor point: I'd be forever having to check whether it's -vV, -Vv, or -VV
If we use the normal verbose flag, then both "-vV" and "-Vv" will work, since options can be provided in any order.
That's a good start, at least.
I don't think it makes sense to also allow "-VV" - we're not requesting the version twice, we're asking for more verbose version information.
It's not as far-fetched as you might think - if "vv" means "more verbose", and "qq" means "more quiet", then "VV" means "more version info".
I'm fine with making "-V" itself a counted option, and hence supporting -VV *instead of* -vV.
The only approach I'm not OK with is allowing both -VV *and* the mixed-case form to request more detailed version information.
Cheers, Nick.
On Mon, Oct 17, 2016 at 5:02 PM, Nick Coghlan ncoghlan@gmail.com wrote:
I'm fine with making "-V" itself a counted option, and hence supporting -VV *instead of* -vV.
The only approach I'm not OK with is allowing both -VV *and* the mixed-case form to request more detailed version information.
Okay. I'd have no problem with that. It's easy enough to ask people to capitalize them both.
Definite +1 from me.
ChrisA
Nick Coghlan writes:
If we use the normal verbose flag, then both "-vV" and "-Vv" will work, since options can be provided in any order.
+0.5 for some such option, +1 for "-VV" or "-V -V"
I for one would likely make that mistake (using "-VV" instead of "-vV") a lot. "python -V" is the first thing I do on somebody else's system when helping them debug, but I rarely use "python -v" in anger. I suspect that I wouldn't use "python -Vv" [sic] often enough to remember it.
-
Chris Angelico -
INADA Naoki -
Nathaniel Smith -
Nick Coghlan -
Sebastian Krause -
Serhiy Storchaka -
Stephen J. Turnbull -
tritium-list＠sdamon.com