Ideas for a module to process command line arguments

[Michele Simionato]

On Jan 12, 6:09 pm, Alice Bevan–McGregor <al... at 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.