Improving the discussion of half clones using gemini 3

[Edward K. Ream]

This gemini3 conversation asks for help in improving #4478, the documentation for rst3 filters and half clones. Note that I started with new writing not contained in #4478.

The analysis was impressive. The actual text needs revision--it feels like a new first draft. Still they improve on my first draft.

I wonder what gemini3 will do with Leo's home page and tutorials...

Edward

[Edward K. Ream]

On Thursday, November 20, 2025 at 4:56:27 AM UTC-6 Edward K. Ream wrote:

This gemini3 conversation asks for help in improving #4478, the documentation for rst3 filters and half clones. Note that I started with new writing not contained in #4478.

Wow: Here is the latest result. It's way better than the first, second, and third drafts:

All clones of the same node share the same VNode, and thus they all have exactly the same headline, body text, and children. Therefore, changing p.b or p.h, or adding a child to one clone modifies the underlying VNode, reflected instantly in all other clones.

However, Leo's users often request a vague enhancement informally known as "half clones." We can make this ill-defined notion precise by saying that we often want to treat clones differently depending on context, the Position of that clone within the entire outline.

It's easy to use positions to tailor the handling of each node. Something like this:

    for p in c.all_positions():
        parent = p.parent()
        if not parent:
            continue
        sib1 = p.next()
        sib2 = sib1 and sib1.next()
        case1 = sib1 and parent.h == 'context1' and sib1.h == 'y'
        case2 = sib2 and parent.h == 'context2' and sib2.b.startswith('@foo')
        if case1:
            << handle case 1 >>
        elif case2:
            << handle case 2 >>

Summary

I got a bit annoyed at the pickiness of some of the suggestions, but in retrospect they were spot on.

Illustrating how to use the context of potentially cloned nodes is worth any amount of work. The example above is a template for tailoring (cutting, pasting, modifying) snippets of documentation that appear in different documentation contexts. This is a challenge posed by Kent Tenney many years ago.

Edward

[Thomas Passin]

Here is a part of a conversation I had with Claude:

Me

----

In some ways I think of Python as being an evolution of Pascal into a more practical, powerful language.

Claude
----------

That's an interesting observation. There are real parallels:

Pascal's strengths that Python inherited:

• Readability as a design goal: Pascal was designed to teach programming clearly. Python kept that philosophy—code should be readable and intent should be obvious.
• Simple, clear syntax: Pascal had straightforward control flow and structure. Python does too—if, for, while, indentation for blocks. No cryptic operators or magical behavior.
• Strong but not restrictive typing: Pascal enforced types but let you work with what you needed. Python has dynamic typing but lets you be precise when you want (type hints).
• Practical orientation: Pascal wasn't trying to be theoretically pure; it was trying to be useful. Same with Python.

But Python went further:

• Pragmatic paradigm mixing: Pascal was procedural with some OO bolted on later. Python said "use what fits."
• Massive standard library: Python gave you tools for real problems, not just language features.
• Community and ecosystem: Python built momentum and libraries that made it practical for everything from scripts to production systems.

[jkn]

I watched the recent "Python: The Documentary" film (https://www.youtube.com/watch?v=GfH4QL4VqJ0) recently, and enjoyed it a lot. I have been programming in Python since around 1999, and the history walked through the features and libraries that have been developed since then, in a way that closely mirrored my sideline observations. There's a comment (from Brett Cannon, I think), which exactly matches my experience: "I came for the language; I stayed for the community"

But anyway ... this started with a little bit on the original language ABC, which Guido developed one Christmas into Python. I would like to know a little more about what he kept, threw away, extended etc. at that point. There was a brief interview with one of Guido's ABC colleagues/mentors, where he says (paraphrasing) "I didn't get what he was doing or why"; I am curious about what this says about any underlying philosophies.