[IPython-dev] Helping battle testing the newapp branch
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.
>>>>>> 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
> 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
> 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.
>> 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
> IPython-dev mailing list
> IPython-dev at scipy.org
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