I used to think getopt needed a lot of changes, but I'm not so sure
anymore. getopt's current API works fine for me and I use it in all
my scripts. However,
>>>>> "DG" == David Goodger <dgoodger@bigfoot.com> writes:
DG> The incompatibility was introduced because the current
DG> getopt() returns an empty string as the optarg (second element
DG> of the tuple) for an argumentless option. I changed it to
DG> return None. Otherwise, it's impossible to differentiate
DG> between an argumentless option '-a' and an empty string
DG> argument '-a ""'. But I could rework it to remove the
DG> incompatibility.
I don't think that's necessary. In my own use, if I /know/ -a doesn't
have an argument (because I didn't specify as "a:"), then I never
check the optarg. And it's bad form for a flag to take an optional
argument; it either does or it doesn't and you know that in advance.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4