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 fir
(Added python-dev in CC list, because there are enough +1 already).
On Mon, Oct 17, 2016 at 3:06 PM, Chris Angelico wrote:
> 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
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
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 hav
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
>>
>> 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, b
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
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.
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
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 spec
>
> 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
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(s
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
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
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?
Sebastian
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
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
o
17 matches
Mail list logo
