On Jan 12, 6:09 pm, Alice Bevan–McGregor <al...@gothcandy.com> wrote: > entirely sure what you mean by 'smart' options. If your'e referring to > using a single hyphen and a list of characters to represent a long > option (which, to the rest of the world, use two leading hyphens) then > that's pretty weird. ;) > > One major system in the world that doesn't really differentiate between > long and short options is... DOS, and by extension, Windows. But they > also use / as a switch character.
Yes, and plac (it is argparse actually) can accomodate the Windows convention by setting the prefix_chars to "/". I wanted to be able to give that freedom even if personally am more used to the GNU double-dash convention. > Anyway; I'm happy with what I have wrought (and am continuing to update > with support for class-based sub-command dispatch) and will be > utilizing it for all scripts in the Marrow suite. To each their own, > but reinvention itself can be for motivations other than NIH. I wanted > something pure-Python, portable across the 3k barrier without code > modification (no 2to3), that didn't use optparse, getopt, or argparse > and basically be a translation layer. It can be simpler than that, as > marrow.script demonstrates. No arguing against that. BTW, I was not criticizing marrow.script, I was simply deploring the situation in the standard library. If the same approach for parsing command-line options is being reinvented by different people multiple times there must be something wrong with the current standard. -- http://mail.python.org/mailman/listinfo/python-list
