[IPython-dev] Helping battle testing the newapp branch

[Robert Kern]

On 6/21/11 12:50 PM, MinRK 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

Okay, I was under a misapprehension, then.

>> 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.

By "unfinished", I meant that one still needs to implement a method to configure 
it. It can't determine what arguments it allows from a data structure in the 
same way that KeyValueConfigLoader does.

And PS: *please* stop Ccing me. I'm subscribed to the list!

-- 
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