Re: New argument processing code merged into devel

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

Re: New argument processing code merged into devel

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

Re: New argument processing code merged into devel

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

Re: New argument processing code merged into devel

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

New argument processing code merged into devel

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