New argument processing code merged into devel

[Edward K. Ream]

PR #3382 is now part of devel. The new code:

- resolves the problems discussed in #3382,

- produces better messages,

- is generally simpler and more flexible.

The code has only been lightly tested. Please report any problems immediately.

Edward

[Edward K. Ream]

On Thursday, June 15, 2023 at 8:06:04 PM UTC-5 Edward K. Ream wrote:

> The code has only been lightly tested. Please report any problems immediately.

Many thanks to Thomas for his testing. Recent PRs and revs have improved error reporting.

I can see how something as horrid as argparse gets started. There is a desire to share code, but this requires endless features and kwargs.

Leo's world contains several modules that use argparse. I'm going to leave them alone because they are seldom used. But if I did want to eliminate argparse everywhere I might define some common helper functions in leoGlobals.

I would not create a faux helper class. Such a class would lead immediately to something like argparse. Oh, let's add just one more feature...

Edward

[Edward K. Ream]

On Friday, June 16, 2023 at 9:12:24 AM UTC-5 Edward K. Ream wrote:

[If] I did want to eliminate argparse everywhere I might define some common helper functions in leoGlobals. I would not create a faux helper class.

On second thought, a stateless class, say g.OptionsUtils, would simply package a set of functions. I am going to experiment with this pattern.

Edward

[Edward K. Ream]

On Friday, June 16, 2023 at 1:46:37 PM UTC-5 Edward K. Ream wrote:

a stateless class, say g.OptionsUtils, would simply package a set of functions. I am going to experiment with this pattern.

Experiments show that just adding four functions to leoGlobals.py is more convenient.

The latest code is in PR #3389.  All comments welcome.

Edward

[Thomas Passin]

One additional idea you might entertain as long as you are thinking about argument parsing functions.  Most command line processing functions return a string, and it is up to the downstream code to convert it to an int, float, whatever.  My own - overly simple, for sure - includes an optional default value in its function signature.  The code returns the argument already cast to the type of the default value.

One might raise the question of separation of concerns - an argument parser doesn't need to know about the argument's types, perhaps - but usually there is a default value provided somewhere, and why not put it in the code that returns the argument?