Progress at PyCon 2023

[rmorshea]

This issue exists to record planning/discussions that occur during PyCon this year.

It seems useful to write down thoughts and ideas that arise for posterity and for those who can't attend in person.

[rmorshea]

I really wish I could be there, but having moved and just changed jobs, the timing just doesn't work out.

[rmorshea]

Wait, @jimbaker you're still in Boulder right? I just moved there...

[jimbaker]

Wait, @jimbaker you're still in Boulder right? I just moved there...

Yes, welcome to Colorado! Maybe we can meet up this week in person, when I get back from Salt Lake City (Tuesday or later). Certainly whenever it works out for both of us.

[jimbaker]

Some items from discussions I have had at PyCon:

1. PyScript can be an important target for us, given that producing HTML fragments is a common use case. (I'm currently in the PyScript open space.)
2. A common reaction is that https://github.com/jimbaker/tagstr/blob/main/tutorial.rst needs to be significantly reworked - it is too long, covers too much information, and doesn't get to the point. So some work there 😁. On the other hand, the tutorial has a lot of useful content that we will want to preserve somewhere, just not in a PEP.
3. Performance and caching is important. This can be readily done (we have worked out some of this for HTML for example). It can be looked at further and discussed in the PEP. a) Performance - for example, someone might write a Rust implementation of an html tag. b) Caching - it's possible to cache on the tag args, specifically the str chunks.

[jimbaker]

An important dependency is PEP 701, which formalizes f-strings. In particular, this PEP relaxes the use of quotes in expressions such that they do not need to be changed, but instead uses the nesting from expressions in the parse.

https://github.com/python/cpython/issues/102856 tracks the work on implementing this PEP, and as of April 19 (last week) is mostly done and merged into main.

[jimbaker]

Lastly there was a question about supporting MicroPython, which has become popular for PyScript. I reviewed https://docs.micropython.org/en/latest/genrst/core_language.html and https://docs.micropython.org/en/latest/develop/memorymgt.html#allocation-of-objects

In principle, this seems doable:

1. I didn't see anything about MicroPython lacking lexical scope, lambda, or frames (necessary to support closures). In particular MicroPython does implement a straightforward mark-and-sweep GC scheme. So it should be possible to implement Thunk.
2. There are some specific restrictions for parsing f-strings, because MicroPython deliberately has a very simple parser that doesn't check for brace matching of embedded expressions. I guess this could apply to anyone looking at implementing PEP 701. However, this would simply mean that tag strings would be as limited as f-strings.

[gvanrossum]

See #22 for a working branch built on top of the most recent main (which includes PEP 701).

[pauleveritt]

2. A common reaction is that https://github.com/jimbaker/tagstr/blob/main/tutorial.rst needs to be significantly reworked - it is too long, covers too much information, and doesn't get to the point. So some work there 😁. On the other hand, the tutorial has a lot of useful content that we will want to preserve somewhere, just not in a PEP.

I'm about to extract this to another ticket.

[pauleveritt]

3. Performance and caching is important. This can be readily done (we have worked out some of this for HTML for example). It can be looked at further and discussed in the PEP. a) Performance - for example, someone might write a Rust implementation of an html tag. b) Caching - it's possible to cache on the tag args, specifically the str chunks.

@jimbaker Do you feel strongly enough about this to track more work in a separate ticket?

[pauleveritt]

Let's close this ticket. The only other actionable work is the MicroPython part, which certainly deserves its own ticket, if work will continue.

[jimbaker]

No need for specific issues on below:

3. Performance and caching is important. This can be readily done (we have worked out some of this for HTML for example). It can be looked at further and discussed in the PEP. a) Performance - for example, someone might write a Rust implementation of an html tag.

Let's capture that separately in a given example, or other discussion. There's no one performance story, other than to acknowledge some common patterns like memoization.

b) Caching - it's possible to cache on the tag args, specifically the str chunks.

So this aspect of a str chunk -- now dubbed Chunk -- is now in the PEP (although it needs more work). We will track it there.

[jimbaker]

Let's close this ticket. The only other actionable work is the MicroPython part, which certainly deserves its own ticket, if work will continue.

:+1: