On Wed, 13 Feb 2002, I wrote:
>Let's get some terminology straight. Howl if you think these
>definitions are bogus:
>
> argument
> something in sys.argv (or possibly sys.argv[1:], depending on
> your PoV)
On 13 February 2002, Ben Wolfson replied (in private email; I
presume this was a mistake, as this really belongs on the list):
> I would prefer it if an option parser did *not* assume the arguments were
> in sys.argv.
First, I don't think that my off-the-cuff definitions should be
interpreted as carved-in-stone specifications for a future (or present)
getopt replacement. But, just to be extra-super-careful, I'll revise
that one:
argument
one of the elements of sys.argv[1:], or a similar list provided
to substitute for sys.argv[1:]
> I prefer doing something like this:
>
> def main(av):
> #parse options in av and do whatever the script does
>
> if __name__ == '__main__':
> main(sys.argv) #or sys.argv[1:]
I think that should be *allowed*, but I also don't like having to
explicitly refer to sys.argv[1:] in every single script I write. That
explains Optik's interface:
parse_args(args : [string] = sys.argv[1:],
values : Values = None)
-> (values : Values, args : [string])
...ie. you can pass in an arg list if you want; if you don't, it uses
sys.argv[1:]. This is *so* obvious to me; I can't understand why other
getopt libraries (in Python at least, where sys.argv is globally
available) aren't like this.
> That way it's possible to import a script and call its main() with your own
> psuedo-command-line arguments.
Key word: *possible*, not required.
Greg
--
Greg Ward - programmer-at-big gward@python.net
http://starship.python.net/~gward/
If at first you don't succeed, redefine success.