Plans for new PRs

52 views
Skip to first unread message

Edward K. Ream

unread,
Jul 18, 2026, 9:41:49 AM (3 days ago) Jul 18
to leo-editor
PR #4801 should mark the end of the recent turbulent period in Leo's development.

If I could change history, I would not have changed Leo's API when I did. First, I should have made only the changes required to satisfy mypy. Larger changes to Leo's API should have come only after the annotation work was complete. Otoh, changing the API early simplified the annotation work.

Anyway, I'll attempt to make future PRs as small and focused as possible.

Use the walrus operator

I have come to love the := operator. A Leonine script will change:

    x = whatever
    if x:
       ...

to:

    if x := whatever:
        ...

This more concise code sometimes helps mypy and other checkers.

Add annotations gradually, without modifying Leo's API

Three separate PRs will require strict annotations in:

- The remaining files in leo/core.
- all files in leo/commands.
- All of Leo's qt gui files.

These PRs will modify Leo's API only if absolutely necessary.

Summary

Future PRs should be smaller, simpler, saner, and safer.

I work on these PRs only after merging the backlog of pending PRs.

Edward

Thomas Passin

unread,
Jul 18, 2026, 10:50:57 AM (3 days ago) Jul 18
to leo-editor
On Saturday, July 18, 2026 at 9:41:49 AM UTC-4 Edward K. Ream wrote:

Use the walrus operator

I have come to love the := operator. A Leonine script will change:

    x = whatever
    if x:
       ...

to:

    if x := whatever:
        ...

I, on the other hand, dislike the walrus operator after trying it out. That's because a statement using the walrus operator does two things. Where one wants to think about what the condition being tested it, the statement muddies the waters by making one also think about how the variable is being generated. Those are two incompatible mental activities, and it's better not to smoosh them together. The only benefit is reducing the line count by one. That's not a strong benefit compared to clarity when reading the code.

If the walrus assignment raises an exception, you don't easily know what happened unless you use a try block around the whole if statement, and recovering from that may be more complicated than recovering from an exception in a separate assignment.

In addition, there are more rules to learn about how to use them (sometimes you have to parenthesize them, but I haven't absorbed all that).

So I'm not a fan though I'm willing to use them very sparingly once in a while.

Edward K. Ream

unread,
Jul 18, 2026, 11:53:12 AM (3 days ago) Jul 18
to leo-e...@googlegroups.com
On Sat, Jul 18, 2026 at 9:50 AM Thomas Passin  wrote:

I, on the other hand, dislike the walrus operator after trying it out.

Well, there's room for disagreement. You may remember that the operator was a super controversial proposal. The acrimony persuaded GvR to renounce the title of BDFL.

I think you overstate the difficulties in using the operator. In any case, Leo's code won't test the operator's edge case. The compiler will complain if I break the rules. Most importantly, the walrus operator sometimes helps mypy do a better job.

Anyway, this is an internal code matter, so I don't think anyone is going to be too put out.

Edward

P.S. I said I would use a Leonine script to add walrus operators, but I think a regex search will be more convenient. I can accept or reject each match interactively.

EKR

Edward K. Ream

unread,
Jul 18, 2026, 1:03:21 PM (3 days ago) Jul 18
to leo-editor
On Saturday, July 18, 2026 at 10:53:12 AM UTC-5 Edward K. Ream wrote:

> I said I would use a Leonine script to add walrus operators, but I think a regex search will be more convenient. I can accept or reject each match interactively.

The following find/repl patterns work well enough:

# find: ^(\s*)([\w]+) \= (.*?)\n\s*if\s*([\w.]+)\:\n
# repl: \1if \2 := \3:

PR #4804 adds the walrus operator to leoApp.py. Doing so revealed some quirps.

However, I am going to put this PR on hold. I just wanted to do a quick proof of concept. It's time to deal with the backlog of other PRs.

Edward

Thomas Passin

unread,
Jul 18, 2026, 1:31:50 PM (3 days ago) Jul 18
to leo-editor
On Saturday, July 18, 2026 at 11:53:12 AM UTC-4 Edward K. Ream wrote:
Well, there's room for disagreement. You may remember that the operator was a super controversial proposal. The acrimony persuaded GvR to renounce the title of BDFL.

I never read about what was behind that renunciation.  Wow.

jkn

unread,
Jul 18, 2026, 1:59:08 PM (3 days ago) Jul 18
to leo-editor
Yes, it caused quite the shock waves.

I recommend the film "Python: The Documentary" on youtube:


It made me very nostalgic for the time (late 1990s/early 2000s) when I first came across python and the community that grew around it.

Edward K. Ream

unread,
Jul 19, 2026, 8:09:18 AM (2 days ago) Jul 19
to leo-editor
On Saturday, July 18, 2026 at 12:03:21 PM UTC-5 Edward K. Ream wrote:

The following find/repl patterns work well enough:

# find: ^(\s*)([\w]+) \= (.*?)\n\s*if\s*([\w.]+)\:\n
# repl: \1if \2 := \3:

 Correction: the "repl" string should end with a newline:

# repl: \1if \2 := \3:\n

Edward
Reply all
Reply to author
Forward
0 new messages