[IPython-dev] Helping battle testing the newapp branch

Brian Granger ellisonbg at gmail.com
Tue Jun 21 15:37:21 EDT 2011


On Tue, Jun 21, 2011 at 10:50 AM, MinRK <benjaminrk at gmail.com> wrote:
> On Tue, Jun 21, 2011 at 09:47, Robert Kern <robert.kern at gmail.com> wrote:
>> On 6/21/11 11:20 AM, Min RK wrote:
>>>
>>> On Jun 21, 2011, at 9:12, Robert Kern<robert.kern at gmail.com>  wrote:
>>>
>>>> On 6/21/11 10:23 AM, Min RK wrote:
>>>>>
>>>>> On Jun 21, 2011, at 1:05, Fernando Perez<fperez.net at gmail.com>   wrote:
>>>>>
>>>>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK<benjaminrk at gmail.com>   wrote:
>>>>>>> newapp has been merged into master.
>>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> BTW, I think we should add back the (ugly, I know) special-case of
>>>>>> honoring -pylab with a single dash.  We've talked about this before,
>>>>>> while it's ugly, this is written in *many* places, including books and
>>>>>> published papers, as the way to start ipython with plotting/numerical
>>>>>> support.  I think it's worth the friendliness to users who arrive via
>>>>>> that path to have that option just work, even if it means an ugly two
>>>>>> lines of code special-casing '-pylab' in sys.argv...
>>>>>
>>>>> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'.  Currently, one '-' cannot be valid, so it is safe to allow it.
>>>>
>>>> Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab"
>>>> for the pylab profile?
>>>
>>> -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people.
>>
>> Well, yes. Changing "-i" to "--i" is just gratuitous, as is disallowing the
>> short aliases for "-p/--profile" and "-l/--log". It makes IPython more
>> non-standard in addition to backwards-incompatible.
>
> The only reason '-' is not allowed for flags now is in case we want to
> add something like short aliases.
>
>> The manual parsing in
>> KeyValueConfigLoader exacerbates this (e.g. it seems to require
>> "--profile=scipy" rather than "--profile scipy" like most applications would
>> accept).
>
> Command-line args are unambiguous - flags, prefixed with `--` *never*
> take arguments, and setting values is always simply a Python
> assignment, thus never prefixed by '-', so now specifying which pylab
> backend to use and using the auto backend are different:
>
> # use matplotlib default:
> ipython --pylab # equivalent to ipython pylab=auto
> # specify Qt:
> ipython pylab=qt
>
> Neither of the following works:
> ipython --pylab=qt
> ipython --pylab qt
>
>
>>
>> I know it's late in the game to be commenting on this, but that's an unpleasant
>> change. I see an ArgParseConfigLoader, but it seems unfinished and unused.
>
> I don't know if it's unfinished, but it's definitely unused.

Yes, this is an important point that we will have to highlight and
clarify in the docs.  We have *completely* moved away from the
argparse style command line parsing.

> The KeyValue command-line args are definitely not as nice as argparse.
>  The advantage, though, is that 100% of configurable IPython is
> available on the command-line, and adding/updating/changing
> configurable traits themselves updates the command-line arguments and
> helpstrings.  Specifying command-line args is also identical to
> specifying the same values in a config file, so users familiar with
> configuring IPython are also familiar with the command-line options.

I am biased because I helped to design the new config system and
command line parsing, but I
do think the new style is a much better approach for IPython that
users will quickly adapt to
and like.  Personally, I actually like this command line syntax
*better* than that of argparse as
it looks more like Python code (it is!) and has a very attractive
uniformity between the code,
command line and config files.  I won't deny though that it is a huge
change though.

Cheers,

Brian

> It's a rough change, and it's going to be difficult/unattractive for
> some people. If people really do hate it, we can drop back to argparse
> in 0.12, but the net effect this change has had on the IPython code
> base itself has been positive.




> -MinRK
>
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless enigma
>>  that is made terrible by our own mad attempt to interpret it as though it had
>>  an underlying truth."
>>   -- Umberto Eco
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com



More information about the IPython-dev mailing list