Thank you! Curious what options for deferred evalution were considered and rejected? IMHO, the main benefit of deferred evaluation isn't in the saving of a bit of code to define a deferred evaluation class, but in standardazing the API so that anyone can read the code without having to learn what it means in each project.

Also: were prompt templates for LLM prompt chaining a use case that influenced the design in any way (examples being LangChain and dozens of other libraries with similar functionlity)?

One solution that existed for a while was using the `!` operator for deferred. `t!'my defered {str}'`

The main reason for non having deferred evaluation was that it over-complicated the feature quite a bit and introduces a rune. Deferred evaluation also has the potential to dramatically increase complexity for beginners in the language, as it can be confusing to follow if you dont know what is going on. Which means "deferred by default" wasnt going to be accepted.

As for LLM's, it was not the main consideration, as the PEP process here started before LLM's were popular.

> were prompt templates for LLM prompt chaining a use case that influenced the design in any way

Maybe not directly, but the Python community is full of LLM users and so I think there's a general awareness of the issues.