[Python-Dev] Python long command line options

Heiko Wundram me+python-dev at modelnine.org
Thu May 4 08:29:52 CEST 2006


Hi all!

Martin von Löwis said that it'd be necessary to discuss a patch to Python's 
ability to parse command-line parameters to the interpreter here, and I 
thought I might start the ball rolling.

The associated patch of mine is:

http://sourceforge.net/tracker/index.php?func=detail&aid=1481112&group_id=5470&atid=305470

which refers to:

http://groups.google.de/group/comp.lang.python/browse_thread/thread/e3db1619040d7c6c/3c119e09122c83ed?hl=de#3c119e09122c83ed

(sorry for the long URLs, tinyurl isn't working for me at the moment...)

The patch itself is an extension of the Python/getopt.c module to handle long 
command-line parameters (including option data passed as --<name>=<data>), 
which are specified in the optstring as:

"<shortopt>[(longopt)][:]"

for example:

"V(version)"

or

"c(command):"

The patch doesn't change behaviour on old optstrings, except where an old 
optstring relied on the fact that one of :, (, ) are valid parameter names 
(because of the unconditional strchr to find the option name). I've not found 
any reference to _PyOS_GetOpt besides the one in Modules/main.c, so I don't 
think this change in behaviour breaks any existing code. The patch relies 
only on usability of strchr (which the old getopt.c did too), removes a usage 
of strcmp which was completely unneccesary, fixes some checks which were 
unneccesarily broad (>= replaced by ==), and compilation doesn't show any 
warnings on gcc 3.4.6; as for Windows (and MSVC), I don't have the means to 
test there.

The current patch offers prefix matching: when an option is only specified 
with a significant amount of prefix characters which doesn't match any other 
long option, the patch assumes that the user meant this option. For example:

--ver

would also be interpreted as command-line parameter

--version

just as would

--v
--ve
--vers
--versi
--versio

if there are no other long options that start with the corresponding prefix. 
This "trick" is easy enough to remove from the sources, though, so that only 
correctly spelled options are actually returned.

Anyway, back on topic, I personally agree with the people who posted to 
comp.lang.python that --version (and possibly --help, possibly other long 
parameters too) would be useful additions to Pythons command-line parameters, 
as it's increasingly getting more common amongst GNU and BSD utilities to 
support these command-line options to get information about the utility at 
hand (very popular amongst system administrators) and to use long commandline 
options to be able to easily see what an option does when encountered in a 
shell script of some sort.

And, as this doesn't break any old code (-V isn't going away by the patch), I 
personally find this to be a very useful change.

Your thoughts?

--- Heiko.


More information about the Python-Dev mailing list