[IPython-dev] Helping battle testing the newapp branch
Tue Jun 21 12:50:27 CDT 2011
On Tue, Jun 21, 2011 at 09:47, Robert Kern <email@example.com> wrote:
> On 6/21/11 11:20 AM, Min RK wrote:
>> On Jun 21, 2011, at 9:12, Robert Kern<firstname.lastname@example.org> wrote:
>>> On 6/21/11 10:23 AM, Min RK wrote:
>>>> On Jun 21, 2011, at 1:05, Fernando Perez<email@example.com> wrote:
>>>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK<firstname.lastname@example.org> 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:
Neither of the following works:
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.
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.
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
More information about the IPython-dev