Re: [Python-ideas] Show more info when `python -vV`

[Chris Angelico]

On Mon, Oct 17, 2016 at 5:02 PM, INADA Naoki  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Chris Angelico]

On Mon, Oct 17, 2016 at 5:02 PM, Nick Coghlan  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Nick Coghlan]

On 17 October 2016 at 15:51, Chris Angelico  wrote:
> On Mon, Oct 17, 2016 at 3:21 PM, Nick Coghlan  wrote:
>> On 17 October 2016 at 13:40, Chris Angelico  wrote:
>>> On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan  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.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Nick Coghlan]

On 16 October 2016 at 04:36, INADA Naoki  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.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Serhiy Storchaka]

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.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Nick Coghlan]

On 15 October 2016 at 03:52, Sebastian Krause  wrote:
> Nathaniel Smith  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.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Chris Angelico]

On Sat, Oct 15, 2016 at 4:52 AM, Sebastian Krause
 wrote:
> Nathaniel Smith  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 "", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes
in position 2-3: truncated \U 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[Nathaniel Smith]

On Fri, Oct 14, 2016 at 9:09 AM,   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 J. Smith -- https://vorpus.org
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Show more info when `python -vV`

[tritium-list]

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@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_API
>   Locally applied patches:
> /Library/Perl/Updates/ 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  <songofaca...@gmail.com>
> ___
> Python-ideas mailing list
> Python-ideas@py