Re: PR #3389 (in devel) concludes work on handling options

[Edward K. Ream]

On Friday, June 16, 2023 at 9:32:42 PM UTC-5 Félix wrote:

devel fails this single test on windows (not sure if related or if its a 
real problem) :


The test works for me with python 3.11 on Windows. I have no idea how it 
could fail for you.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/29a33fe9-28f9-47cb-b879-9be2682a0181n%40googlegroups.com.

Open new window

[Rand Batchelder]

Can I write a script in Leo, which will create a new window in which I can 
display some graphics ?

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fba34fbd-18a0-492a-bf1f-40568b31a83an%40googlegroups.com.

Re: PR #3389 (in devel) concludes work on handling options

[Félix]

devel fails this single test on windows (not sure if related or if its a 
real problem) :

./leo/unittests/core/test_leoImport.py::TestLeoImport::test_recursive_import 
Failed: 'path: ekr-mypy2/mypy' != 'path: mypy'
- path: ekr-mypy2/mypy
+ path: mypy

  File "C:\Python311\Lib\unittest\case.py", line 57, in testPartExecutor
yield
  File "C:\Python311\Lib\unittest\case.py", line 623, in run
self._callTestMethod(testMethod)
  File "C:\Python311\Lib\unittest\case.py", line 579, in _callTestMethod
if method() is not None:
   
  File "c:\prog\leo-editor\leo\unittests\core\test_leoImport.py", line 106, 
in test_recursive_import
self.assertEqual(root.h, expected)
AssertionError: 'path: ekr-mypy2/mypy' != 'path: mypy'
- path: ekr-mypy2/mypy
+ path: mypy

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

> PR #3389  defines 
> four simple helper functions in leoGlobals.py.
>
> Imo these four functions do more than the entire argparse module. They are 
> simpler, easier and more flexible.
>
> Thanks again to Thomas for his careful reading of the code.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e8957739-b6fd-4cea-b440-8f8cff1bcbean%40googlegroups.com.

PR #3389 (in devel) concludes work on handling options

[Edward K. Ream]

PR #3389  defines four 
simple helper functions in leoGlobals.py.

Imo these four functions do more than the entire argparse module. They are 
simpler, easier and more flexible.

Thanks again to Thomas for his careful reading of the code.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/92052942-d641-40f8-8c1d-16fc1b2e2f85n%40googlegroups.com.

Re: New argument processing code merged into devel

[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?

On Friday, June 16, 2023 at 3:23:49 PM UTC-4 Edward K. Ream wrote:

> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/df0f1ae0-faad-47e1-83a6-ddae407fb7dfn%40googlegroups.com.

Re: New argument processing code merged into devel

[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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c9abca0a-48a3-4cc1-b19f-c409e68c3a44n%40googlegroups.com.

Re: New argument processing code merged into devel

[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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f06a24e0-8eb0-4bec-b466-fb2be984b069n%40googlegroups.com.

Re: New argument processing code merged into devel

[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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4f8d6f09-1d64-444b-9625-f36d1446a06dn%40googlegroups.com.