[IPython-dev] Argument parsing (was: Qt api selection re. ipython and matplotlib)

[MinRK]

On Thu, Jul 7, 2011 at 07:00, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Jul 6, 2011 at 2:19 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 11:06 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:
>>>> By the way, I find the new ipython's new argument parsing really
>>>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>>>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>>>> with "ipython --gui=qt"? Does ipython really need to put its own
>>>> unique spin on argument parsing?
>>>
>>> The reason for Brian's design here is that now the command line args
>>> are coupled with the config system.  Specifying a value on the command
>>> line is now identical to specifying it in a config file, so it looks
>>> like a Python assignment (because it is).  It also means that 100% of
>>> IPython is configurable from the command-line.
>>
>> As Min mentions, the config system syntax *is* Python and we wanted to
>> use a syntax that reflected that.  When you do:
>>
>> Foo.bar=10
>>
>> At the command line, we parse that as Python code and run it through
>> the traits machinery.  Making this:
>>
>> --Foo.bar=10
>>
>> Only obscures the fact that it is parsed as Python.
>
> That's a bit hyperbolic. I could then argue that "ipython profile
> create" only makes it confusing to figure out what arguments should be
> treated as options and what arguments should be treated as files.
>
>> This approach
>> also allows us to do things like the following at the command line:
>>
>> Foo.bar=[0,1,2]
>>
>> or even:
>>
>> Foo.bar=range(3)
>>
>> Which is then validated by traits as a list of ints.  We do realize
>> that there is going to be an adjustment period for users and we do
>> need to continue to improve documentation to point out these important
>> changes.
>
> Could you please include some documentation on how I can invoke
> ipython to run a script without a .py or .ipy extension? Lets say I
> have a python script called "profile", this doesn't work:
>
> ipython profile
>
> Or, suppose I have a file named something pathological like foo=bar?
> Python will run it without any problems. Even if I rename it
> foo=bar.py, ipython appears to interpret it as an option, not a
> filename.

You can always give more path information, so `ipython ./profile` or
`ipython ./foo=bar` will work*.  Python has the exact same
vulnerability to pathological filenames matching their argument
patterns, like files called '-foo' or '-zebulon'. Obviously, given our
more flexible syntax, our cases cast a wider net.

*I just noticed that IPython artificially requires '.py', which I
can't find any justification for, so I removed it.  These commands do
work in master.

-MinRK

>
> Darren
>