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

[Ilan Schnell]

That's good to hear, I don't want to be the one responsible
for keeping 'pylab=inline' around :-)

- Ilan


On Fri, Jul 8, 2011 at 12:32 AM, MinRK <benjaminrk at gmail.com> wrote:
> On Thu, Jul 7, 2011 at 20:42, Ilan Schnell <ischnell at enthought.com> wrote:
>>> only because 0.11.rc1 got into EPD
>>
>> I hope this is not the only reason.  We will probably do an EPD
>> bug fix release in a few weeks, in which I'm planing to update
>> to 0.11 final.
>
> That helps a lot, thanks for reminding us, Ilan.  Now that I read
> that, I'm pretty sure you told us this earlier, but my brain is pretty
> fried right now.  This takes some pressure off, and we can make sure
> we get it right, without worrying about 6 months of EPD users having
> an IPython that doesn't match those before or after.
>
> We will favor natural argparse-style arguments, even if we don't
> finish migrating to argparse itself, and the vociferously opposed
> 'foo=value' without leading hyphens will likely be removed. master is
> currently in a temporary state that supports both.
>
> -MinRK
>
>>
>> - Ilan
>>
>>
>> On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> We have relaxed the syntax in 0.11, so you can do the more familiar
>>> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
>>> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
>>> into EPD, but I think we will remove it in 0.12.  I also added support
>>> for '--' to halt parsing, as Robert described.
>>>
>>> Since we aren't doing unusual things for the simple cases, I opened an
>>> issue to replace the existing machinery for everything short of fully
>>> specified Class.trait=value with argparse, and only using our extra
>>> code for that single case, since it just makes more sense. I don't
>>> believe this will happen in 0.11.
>>>
>>> @Julian '-i' should work fine now (its alias was --i, since we used to
>>> require two leading '-' for flags, as described in the help output).
>>> We don't (and won't) support 'ipython -c "stuff"' until we go back to
>>> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
>>> master, '--c=stuff'), as described in the help output, until then.  I
>>> also believe I fixed the inherited-argv bug for scripts that you
>>> described.
>>>
>>> -MinRK
>>>
>>> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>>>> On 7/7/11 11:32 AM, MinRK wrote:
>>>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com>  wrote:
>>>>
>>>>>> 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.
>>>>
>>>> Well, with argparse, you can use the standardized "--" marker to indicate that
>>>> everything following is an argument, not an option. E.g.
>>>>
>>>>   $ ipython -pylab -- -foo.py
>>>>
>>>> --
>>>> 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
>>>
>>
>