Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Progress at PyCon 2023 #21

Closed
rmorshea opened this issue Apr 22, 2023 · 12 comments
Closed

Progress at PyCon 2023 #21

rmorshea opened this issue Apr 22, 2023 · 12 comments
Assignees

Comments

@rmorshea
Copy link
Collaborator

rmorshea commented Apr 22, 2023

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 rmorshea changed the title Progress at PyCon 2023? Progress at PyCon 2023 Apr 22, 2023
@rmorshea
Copy link
Collaborator Author

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

@rmorshea
Copy link
Collaborator Author

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

@jimbaker
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

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.

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

@jimbaker
Copy link
Owner

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
Copy link
Collaborator

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

@pauleveritt
Copy link
Collaborator

  1. 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
Copy link
Collaborator

  1. 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
Copy link
Collaborator

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
Copy link
Owner

jimbaker commented Jul 3, 2023

No need for specific issues on below:

  1. 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
Copy link
Owner

jimbaker commented Jul 3, 2023

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 jimbaker closed this as completed Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants