Library for handling GNU parameters

[Florian Lindner]

Hello,
is there a python library available for handling GNU parameters. For
example:

prog --filename=foo.bar is the same as prog -f foo.bar

or

prog --execute == prog -e

I look for a library for parsing these string and represent the values in a
list.

Thx,
Florian

 

[Peter Hansen]

is there a python library available for handling GNU parameters. For
example:

prog --filename=foo.bar is the same as prog -f foo.bar

or

prog --execute == prog -e

I look for a library for parsing these string and represent the values in a
list.

The standard library module getopt can do that, at least for the sort
of example you show, and I suspect the newer standard library module
optparse could also handle it (but haven't tried myself).

-Peter

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Peter Hansen]

The standard library module getopt can do that, at least for the sort
of example you show, and I suspect the newer standard library module
optparse could also handle it (but haven't tried myself).

I think I read that `optparse' is not going to handle optional arguments
that we find in some commands, and which GNU `getopt' (and also the old
standard `getopt', if I remember well) do handle. As this is a design
choice for `optparse', it might never fully replace `getopt'.

 

[Yermat]

Peter Hansen a écrit :

The standard library module getopt can do that, at least for the sort
of example you show, and I suspect the newer standard library module
optparse could also handle it (but haven't tried myself).

-Peter

Standard Module optparse

http://www.python.org/doc/2.3.3/lib/module-optparse.html

Note that if you do not have python2.3 you can just put the optparse.py
and put it in you python2.2 directory, it will work !

 

[David Goodger]

> I think I read that `optparse' is not going to handle optional
> arguments that we find in some commands,

Do you mean "optional option arguments"? Where an option has an
optional argument? I believe this idea was discussed on the
optik-users list, but it was determined that such a thing is not
reliably parseable.

> and which GNU `getopt' (and also the old
> standard `getopt', if I remember well) do handle.

getopt.py does *not* handle "optional option arguments" either.

If you meant optional positional arguments, optparse and getopt both
support them (by leaving the logic up to the client program).

-- David Goodger

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[David Goodger]

Do you mean "optional option arguments"? Where an option has an
optional argument?

Within GNU `getopt', it is requested by a double colon after an
option letter in the option string, and with the predefined constant
`optional_argument' in the second position of a `struct option'
entry (the two other predefined constants being `no_argument' and
`required_argument').

I believe this idea was discussed on the optik-users list, but it was
determined that such a thing is not reliably parseable.

GNU `getopt' parses it. Yet, users have to be careful while providing
the optional value, for complying with the rules. About if this is the
parser, or the user, not being reliable, is a debatable question .

getopt.py does *not* handle "optional option arguments" either.

I noticed. When I translated Recode to Python, I had to devise a stunt
around this limitation.

If you meant optional positional arguments, optparse and getopt both
support them (by leaving the logic up to the client program).

. By leaving the logic up to the client program, every module
could be said to support every thinkable feature! This is not exactly
what we usually mean by "support"!