Sprinting @ PyCon 2017 WAS: [brython] Brython 3.3.2 released

[Olemis Lang]

On Wed, May 17, 2017 at 8:20 AM, Pierre Quentel <pierre....@gmail.com> wrote:

By Brython standards, it's been a very long time since the last version - more than 3 months !

Version 3.3.2 is mostly a bug fix release. It also adds a demo page in the project home page.

Can we schedule a sprint in PyCon ? I was wondering what we could share with the team implementing BeeWare [1]_ . They have a transpiler for Python bytecode which outputs Java and Javascript [2]_ . Their idea is quite big but as far as I can tell their main .

From my perspective , I'd like to explore two main branches of development :

- Implementing a bytecode VM for Brython

- Transpile Python bytecode into JS code

- Transpile Python bytecode into WebASM (rather than asm.js ) for at least Firefox +52 in experimental mode 

- Implement a GUI package playing well with Python as well as well known JS libraries e.g. dojo, angular, widget toolkits ... 

- I do not know if we should push towards multi-platform requirements; would be nice but lots of efforts 

What d'u think ? Makes sense ? We have to catch up & turn on the engines ;)

p.s. Glyph u still in Portland ? Chance to join if we schedule ? Pierre chance for you to be available online ?

I'm in #PDX BTW and stay for sprints , that's why I ask .

.. [1] https://us.pycon.org/2017/schedule/presentation/166/

.. [2] https://www.youtube.com/watch?v=9c4DEYIXYCM

.. [3] https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/

--

Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Brython committer
http://brython.info
http://github.com/brython-dev/brython

SciPy Latin America - Cuban Ambassador
Chairman of SciPy LA 2017 - http://scipyla.org/conf/2017

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Olemis Lang]

On Sun, May 21, 2017 at 1:32 AM, Olemis Lang <ole...@gmail.com> wrote:

On Wed, May 17, 2017 at 8:20 AM, Pierre Quentel <pierre....@gmail.com> wrote:

By Brython standards, it's been a very long time since the last version - more than 3 months !

Version 3.3.2 is mostly a bug fix release. It also adds a demo page in the project home page.

Can we schedule a sprint in PyCon ? I was wondering what we could share with the team implementing BeeWare [1]_ . They have a transpiler for Python bytecode which outputs Java and Javascript [2]_ . Their idea is quite big but as far as I can tell their main .

From my perspective , I'd like to explore two main branches of development :

- Implementing a bytecode VM for Brython

- Transpile Python bytecode into JS code

- Transpile Python bytecode into WebASM (rather than asm.js ) for at least Firefox +52 in experimental mode 

- Implement a GUI package playing well with Python as well as well known JS libraries e.g. dojo, angular, widget toolkits ... 

- I do not know if we should push towards multi-platform requirements; would be nice but lots of efforts 

- Add an async core to Brython to this list .

 

What d'u think ? Makes sense ? We have to catch up & turn on the engines ;)

p.s. Glyph u still in Portland ? Chance to join if we schedule ? Pierre chance for you to be available online ?

I'm in #PDX BTW and stay for sprints , that's why I ask .

.. [1] https://us.pycon.org/2017/schedule/presentation/166/

.. [2] https://www.youtube.com/watch?v=9c4DEYIXYCM

.. [3] https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/

[Pierre Quentel]

I watched the Snek presentation and I must say I was disappointed.

First the comparison with other solutions (Brython, Skulpt and pypy.js) was mostly based on the size of the Javascript file, which is actually several Mbs for pypy.js, but around 600 Kb for Brython, roughly the same as Batavia.

More important, there was no mention of performance, and the speaker could not give any information when someone asked the question. I am convinced that the result is slow, probably even *very* slow (the Batavia documentation says "an order of magnitude slower than CPython") : the runtime engine that runs the Python bytecode probably uses high-level data structures to push and pop objects in and from the stacks.

I have read the excellent post "500 lines of Python : a Python interpreter written in Python" by Allison Kaptur, also mentioned in the Snek presentation, and tried to implement something similar in Javascript a few weeks ago : I could make a few operations work, but the result was terribly slow.

Another thing that is not well explained is the coverage of Python syntax.

Regarding Olemis's suggestions :
- implementing a bytecode VM for Brython : how and why could we do that ? Brython doesn't produce any bytecode, it parses the Python code and translates it into Javascript
- transpile Python bytecode into Javascript or WebASM : this may be an interesting approach, but once again very different from Brython
- implement a GUI package : I like this idea ! For the moment we only have the option to use JS libraries such as jQueryUI (which is included in the Brython distribution), but a Python web-oriented GUI would be great
- async core : this has been suggested a few times. I am not comfortable with the idea, mostly because I am not comfortable with this programming style... Jonathan implemented asyncio in a previous version, but async and await are currently not supported. Anyway, do we really need a Python async mode ? There is already an event loop running in the browser, and we handle events with the event handlers attached to the DOM elements. Which other event loops do we need that would require async and await ?
 

[Olemis Lang]

Hello Pierre

I'm a bit aware about this . Overall speaking , my initial idea is as follows , they are organizing a sprint for Beeware tools, let's see what is it about . In advance I tell you they do not have an import system like ours , they do not optimize like is the case for PyPy.js , publicly they only support Python 3.5 (though 3.4 worked just fine - I attended their tutorial session) , and in part due to the incompatibilities of Python bytecode from one version to another , they were not even aware of the VFS format we use and why it makes a difference , etc , etc, ... Nevertheless , I'd like to be able to say more about it based on an opinionated understanding of their current state and how it will evolve . On  the other fact it is a fact : they have an extraordinary vision when it comes to implementing multi-platform Python apps with native UI . I wrote Python code in my Mac OS laptop for their demo app and run it:

- from the command line

- as a native (compiled) MacOS .app

- as a web app built with Django

- as a native (msi + exe) Windows app compiled inside my Windows machine (because Windows exec files can only be generated on Windows, afaik)

- as a native (tiny) Android app on my Samsung tablet 

... and I did not change a single line of code . So they have an MVP and are delivering something many of us have been waiting for a while .

Brython is far from being perfect , and if we want to improve it the first thing is to acknowledge that this is the case ... and Batavia approach could still be useful to implement import 

Hope you had traveled to PyCon Pierre , first to know you in person and talk , secondly to program side-by-side and discuss a few ideas I have about possible future developments in Brython .

Now to your message ...

On Sun, May 21, 2017 at 12:24 PM, Pierre Quentel <pierre....@gmail.com> wrote:

I watched the Snek presentation and I must say I was disappointed.

First the comparison with other solutions (Brython, Skulpt and pypy.js) was mostly based on the size of the Javascript file

[...]

No further comments, just the fact that they are aware of PyPy.js and are working on Ouroboros [1]_

 

More important, there was no mention of performance, and the speaker could not give any information when someone asked the question. I am convinced that the result is slow, probably even *very* slow (the Batavia documentation says "an order of magnitude slower than CPython") : the runtime engine that runs the Python bytecode probably uses high-level data structures to push and pop objects in and from the stacks.

Yes and no , their real plans are to translate Python bytecode 1 to 1 (or alike) to WebAssembly executed and optimized by browsers , in a web similar to what they do with VOC [2]_ to compile Python into native apps for Android

 

I have read the excellent post "500 lines of Python : a Python interpreter written in Python" by Allison Kaptur, also mentioned in the Snek presentation, and tried to implement something similar in Javascript a few weeks ago : I could make a few operations work, but the result was terribly slow.

As Javascript code , agreed . The idea is to compile to WebAssembly and run it in Firefox 52 and see how it goes .

 

Another thing that is not well explained is the coverage of Python syntax.

Regarding Olemis's suggestions :
- implementing a bytecode VM for Brython : how and why could we do that ? Brython doesn't produce any bytecode, it parses the Python code and translates it into Javascript
- transpile Python bytecode into Javascript or WebASM : this may be an interesting approach, but once again very different from Brython

In either case starting from bytecode is just to make things easier . We could compile Python code directly into WebAssembly . That would be a direction I'd suggest looking forward . Next step would be to optimize code (peephole, type inference, ...) .

 

- implement a GUI package : I like this idea ! For the moment we only have the option to use JS libraries such as jQueryUI (which is included in the Brython distribution), but a Python web-oriented GUI would be great

What I'd like to have is something quite similar to what BeeWare is proposing that I'm starting to think that it's the same . The way I see it this would be a high-level code describing GUI that could be translated into different environments (e.g. dojo, Bootstrap js widgets, jquery UI , Zurb , ...) afterwards , which means that the same Python code will work no matter what .js framework is underneath .

 

- async core : this has been suggested a few times. I am not comfortable with the idea, mostly because I am not comfortable with this programming style... Jonathan implemented asyncio in a previous version, but async and await are currently not supported.

JFTR , I'm not talking of implementing Python async features in Brython , I'm talking of generating async JS code out of Python syntax .

 

Anyway, do we really need a Python async mode ?

Yes , it seems that Brython will not work on Tizen devices , say, Samsung Gear smartwatches. unless we have an async core .

 

There is already an event loop running in the browser, and we handle events with the event handlers attached to the DOM elements. Which other event loops do we need that would require async and await ?

Tizen implementation is way more constrained and , as it stands today , code generated by Brython blocks the system due to the synchronous of the code it generates , afaict .

.. [1] https://pybee.org/project/projects/libraries/ouroboros/

.. [2] https://pybee.org/project/projects/bridges/voc/

[Olemis Lang]

On Sun, May 21, 2017 at 6:59 PM, Olemis Lang <ole...@gmail.com> wrote:

Another thing that is not well explained is the coverage of Python syntax.

They do not have to, the input of their transpiler is Python bytecode so the Python interpreter already did its job ;)

[Olemis Lang]

On Sun, May 21, 2017 at 6:59 PM, Olemis Lang <ole...@gmail.com> wrote:

Regarding Olemis's suggestions :
- implementing a bytecode VM for Brython : how and why could we do that ? Brython doesn't produce any bytecode, it parses the Python code and translates it into Javascript
- transpile Python bytecode into Javascript or WebASM : this may be an interesting approach, but once again very different from Brython

In either case starting from bytecode is just to make things easier . We could compile Python code directly into WebAssembly . That would be a direction I'd suggest looking forward . Next step would be to optimize code (peephole, type inference, ...) .

 

Considering the title , this is along the lines of what I'd like t know .

https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/

[Olemis Lang]

On Sun, May 21, 2017 at 7:18 PM, Olemis Lang <ole...@gmail.com> wrote:

On Sun, May 21, 2017 at 6:59 PM, Olemis Lang <ole...@gmail.com> wrote:

Regarding Olemis's suggestions :
- implementing a bytecode VM for Brython : how and why could we do that ? Brython doesn't produce any bytecode, it parses the Python code and translates it into Javascript
- transpile Python bytecode into Javascript or WebASM : this may be an interesting approach, but once again very different from Brython

In either case starting from bytecode is just to make things easier . We could compile Python code directly into WebAssembly . That would be a direction I'd suggest looking forward . Next step would be to optimize code (peephole, type inference, ...) .

 

Considering the title , this is along the lines of what I'd like t know .

https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/

which seems to lead to this one 

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

[Eric S. Johansson]

On Sunday, May 21, 2017 at 3:24:09 PM UTC-4, Pierre Quentel wrote:

- implement a GUI package : I like this idea ! For the moment we only have the option to use JS libraries such as jQueryUI (which is included in the Brython distribution), but a Python web-oriented GUI would be great

I'm working on a project with materializecss. how would people feel about starting with that as a base? 

 

[Kiko]

I think this should be a side project independent from the main brython repo.

I would try to be independent from css/js libs/frameworks (they come and go very fast and why one over others).

My 2 cents: there are several attempts to do so and, in general, people end up coding because RADs would be always limited. The best I can think in the Python world is QtDesigner, is great, but I prefer to code using the widgets and the rest of the stuff of the library because, in the end, if I use only QtDesigner I have a small part of the app if it is more complex than a dummy demo. The kivy project is a good example of good effort with a lot of ideas and good intentions but that is not widely adopted (IMHO, I don't have stats). If you want to create a HTML GUI library I would inspect before what others are doing in the python/js world:

https://github.com/dddomodossola/remi
https://phosphorjs.github.io/ (this is used to create the widgets (ipywidgets) in the Jupyter notebook, https://github.com/jupyter-widgets/ipywidgets/search?utf8=%E2%9C%93&q=phosphor&type=).

I think the second option is a good option but it is very focused in dashboards. It seems quite succesful because the jupyter notebook is very extended and quite ubiquituous nowadays and they have economic support (I think continuum has provided some money to the development of phosphor and the whole jupyter project have full time people working on it).

What I want to say is that even with resources it would be a dificult task.

Kind regards.

[Goffi]

Le dimanche 21 mai 2017, 21:24:09 CEST Pierre Quentel a écrit :
> Anyway, do we really need a Python async
> mode ? There is already an event loop running in the browser, and we handle
> events with the event handlers attached to the DOM elements. Which other
> event loops do we need that would require async and await ?

Hi,

I'm following Brython from the distance since 2015, and it's a really nice and
promising project.
We are working on a XMPP communication tool (blogging, file sharing, chat, etc)
name "Salut à Toi" (https://salut-a-toi.org).
It's Python/Twisted based and so fully async, and we have many frontend
including a web one which is using the now dead (unfortunately) Pyjamas.

We are eveluating moving from Pyjamas to Brython, and so far we are mainly
worying about performance, but that's an other debate.

I'm talking about that here because the web frontend is evolving to a web
framework, using Jinja2 as template engine. So it's an async/XMPP based web
framework, and I would like to be able to integrate Brython for browser part
(and maybe optionnaly Transcrypt or other transpiler).
In this regards, the support of async/await would be really useful, specially
if you considere that jinja2 is supporting them.

So yes there would be a need to support these keywords.

If you are interested in this work, I should write blog post about it soon.

Regards
Goffi

[Olemis Lang]

On Mon, May 22, 2017 at 8:33 AM, Kiko <kikoco...@gmail.com> wrote:

2017-05-22 16:50 GMT+02:00 Eric S. Johansson <ynotla...@gmail.com>:

On Sunday, May 21, 2017 at 3:24:09 PM UTC-4, Pierre Quentel wrote:

- implement a GUI package : I like this idea ! For the moment we only have the option to use JS libraries such as jQueryUI (which is included in the Brython distribution), but a Python web-oriented GUI would be great

I'm working on a project with materializecss. how would people feel about starting with that as a base? 

I think this should be a side project independent from the main brython repo.

I would try to be independent from css/js libs/frameworks (they come and go very fast and why one over others).

+1

[Olemis Lang]

On Mon, May 22, 2017 at 9:16 AM, Goffi <go...@goffi.org> wrote:

I'm following Brython from the distance since 2015, and it's a really nice and
promising project.
We are working on a XMPP communication tool (blogging, file sharing, chat, etc)
name "Salut à Toi" (https://salut-a-toi.org).
It's Python/Twisted based and so fully async, and we have many frontend
including a web one which is using the now dead (unfortunately) Pyjamas.

This is the kind of things that reinforces my idea that we should meet more often with persons interested in Brython as a project , so that we can learn from their requirements and they can reach to us with feedback on what's blocking them to adopt Brython , hopefully fix issues altogether .

Right now I'm at Beeware sprint room ( B119 for people who want to join in PDX OCC ) . The idea initially was to implement the import mechanism , like I did for Brython , but I am not keen to repeating myself . Instead I'd rather prefer to implement a whole new BeeWare platform powered by Brython . Worth to try ? I say , we have four sprint days ... let's integrate Brython and see how it behaves . Good idea ?

[Olemis Lang]

On Mon, May 22, 2017 at 11:36 AM, Olemis Lang <ole...@gmail.com> wrote:

Right now I'm at Beeware sprint room ( B119 for people who want to join in PDX OCC ) . The idea initially was to implement the import mechanism , like I did for Brython , but I am not keen to repeating myself . Instead I'd rather prefer to implement a whole new BeeWare platform powered by Brython . Worth to try ? I say , we have four sprint days ... let's integrate Brython and see how it behaves . Good idea ?

I'm moving forward with this . Who follows ? Join us in https://gitter.im/pybee/sprint 

[Roger Erens]

Op maandag 22 mei 2017 18:19:15 UTC+2 schreef Goffi:

Le dimanche 21 mai 2017, 21:24:09 CEST Pierre Quentel a écrit :
> Anyway, do we really need a Python async
> mode ? There is already an event loop running in the browser, and we handle
> events with the event handlers attached to the DOM elements. Which other
> event loops do we need that would require async and await ?

Hi,

...

So yes there would be a need to support these keywords.

And I would really like to use Brython with Autobahn, for which a JS and Python client (amongst other languages) exist to connect to a WAMP-router, like Crossbar.

Think management of IoT devices in the browser. Or: RPC and Pub-Sub in an all-in-one protocol.

For more info: crossbar.io/autobahn

If you are interested in this work, I should write blog post about it soon.

Can't wait to read it! 

Regards
Goffi

Regards,

Roger 

[Olemis Lang]

On Mon, May 22, 2017 at 12:43 PM, Roger Erens <snere...@gmail.com> wrote:

Op maandag 22 mei 2017 18:19:15 UTC+2 schreef Goffi:

Le dimanche 21 mai 2017, 21:24:09 CEST Pierre Quentel a écrit :
> Anyway, do we really need a Python async
> mode ? There is already an event loop running in the browser, and we handle
> events with the event handlers attached to the DOM elements. Which other
> event loops do we need that would require async and await ?

Hi,

...
So yes there would be a need to support these keywords.

And I would really like to use Brython with Autobahn, for which a JS and Python client (amongst other languages) exist to connect to a WAMP-router, like Crossbar.

Think management of IoT devices in the browser. Or: RPC and Pub-Sub in an all-in-one protocol.

For more info: crossbar.io/autobahn

A common subject in MicroPython talks , btw .

[Olemis Lang]

On Mon, May 22, 2017 at 12:51 PM, Olemis Lang <ole...@gmail.com> wrote:

On Mon, May 22, 2017 at 12:43 PM, Roger Erens <snere...@gmail.com> wrote:

Op maandag 22 mei 2017 18:19:15 UTC+2 schreef Goffi:

Le dimanche 21 mai 2017, 21:24:09 CEST Pierre Quentel a écrit :
> Anyway, do we really need a Python async
> mode ? There is already an event loop running in the browser, and we handle
> events with the event handlers attached to the DOM elements. Which other
> event loops do we need that would require async and await ?

Hi,

...
So yes there would be a need to support these keywords.

And I would really like to use Brython with Autobahn, for which a JS and Python client (amongst other languages) exist to connect to a WAMP-router, like Crossbar.

Think management of IoT devices in the browser. Or: RPC and Pub-Sub in an all-in-one protocol.

For more info: crossbar.io/autobahn

A common subject in MicroPython talks , btw .

Indeed MicroPython devices have built-in web repl capabilities

[Jonathan Verner]

I was a bit out of touch with Brython for a while... But I have a few notes:

- async core : this has been suggested a few times. I am not comfortable with the idea, mostly because I am not comfortable with this programming style... Jonathan implemented asyncio in a previous version, but async and await are currently not supported. Anyway, do we really need a Python async mode ? There is already an event loop running in the browser, and we handle events with the event handlers attached to the DOM elements. Which other event loops do we need that would require async and await ?

Unfortunately (or fortunately, depending on how you look at it), there's no way around writing async code in the browser. Python's async/await features make writing async code much  more palatable. The example I provided in the documentation:

@asyncio.coroutine
def process_urls(urls):
    sources = []
    for u in urls:
        req = yield from asyncio.HTTPRequest(u)
        sources.append(req.response.data)
    # process sources
    return results

would be much more messy to write using traditional javascript call-back style (although I think even Javascript is going to have a async/await soon). 

By the way, I've created a simple version of asyncio which strips out all the stuff which is unnecessary in the browser. I will try to merge it soon.

JFTR , I'm not talking of implementing Python async features in Brython , I'm talking of generating async JS code out of Python syntax . 

Anyway, do we really need a Python async mode ? 

Yes , it seems that Brython will not work on Tizen devices , say, Samsung Gear smartwatches. unless we have an async core .

There is already an event loop running in the browser, and we handle events with the event handlers attached to the DOM elements. Which other event loops do we need that would require async and await ? 

Tizen implementation is way more constrained and , as it stands today , code generated by Brython blocks the system due to the synchronous of the code it generates , afaict .

Actually, even in the regular browser being able to generate async JS would be fantastic. Right now, for example, if you are importing a big library,

the browser just freezes until everything is downloaded, compiled and initialized. Another usecase that comes to mind is that we could write 

a step-by-step debugger for python code. And there's certainly plenty of others...

Regarding event loops, there's no need for any other event loop except the one we already have in the browser (that's by the way the only eventloop supported by my implementation of asyncio).

- implement a GUI package : I like this idea ! For the moment we only have the option to use JS libraries such as jQueryUI (which is included in the Brython distribution), but a Python web-oriented GUI would be great

I'm working on a project with materializecss. how would people feel about starting with that as a base? 

I think this should be a side project independent from the main brython repo.

I would try to be independent from css/js libs/frameworks (they come and go very fast and why one over others).

I also thing that this should be a side project. But it would also be nice to have at least a page with links to different projects so that it is easier for people to find them. Eventually, having some kind of

pip tool for brython would be fantastic (another option would be to leverage standard pip and distribute packages with names starting with 'brython-'; I am not sure whether that would not be frowned upon  though...;)

I would try to be independent from css/js libs/frameworks (they come and go very fast and why one over others).

I sort of agree. I think Brython is more likely to attract Python people than Javascript people. And then it would make more sense to come up with a library along the lines of something Python people already know (PyQt, Tk, Django, Jinja2, ...).

Right now, because of a personal project I am working on, I am in the process of creating a widget library. The style looks a bit like Qt widgets, though it is far from a publishable state. The interesting

part about it is, that I am using Django for server-side of the project and I've been able to implement stubs for some django classes so that, you can almost import your models as is into a Brython

application and access them in the browser, e.g. writing:

from widgets import DataListView
from myapp.models import Person


view = DataListView(Person.objects.all())


document['people'] <= view.elt



And have a nice list of all the people in your myapp_Person table show up on your page. 

The plan is to eventually also implement templates along the lines of Django Templates or Jinja2 templates and render them into the dom, automatically updating the dom if the context for the template changes (as, e.g., angular templates do) and also having bidirectional binding between the context and form-fields. I am not sure, whether anyone would be interested in this, but I can put up a wip repo somewhere if this sounds like something you would like to look at.

This is the kind of things that reinforces my idea that we should meet more often with persons interested in Brython as a project , so that we can learn from their requirements and they can reach to us with feedback on what's blocking them to adopt Brython , hopefully fix issues altogether .

I definitely think that is a good idea and I am sorry I missed the sprint. Being in Europe and having a day job there's no way i could've attended in person, but at least I could have been online :-(

BTW sorry about the double post, this google.groups interface has a habit of posting my unfinished drafts :-(

[Eric S. Johansson]

On Tuesday, June 6, 2017 at 6:50:34 AM UTC-4, Jonathan Verner wrote:

I sort of agree. I think Brython is more likely to attract Python people than Javascript people. And then it would make more sense to come up with a library along the lines of something Python people already know (PyQt, Tk, Django, Jinja2, ...).

I mildly disagree. The reason I suggested materialize CSS is because there is a heavy draft in the direction of Google's Material style guide. There's a second heavy draft in the direction of the Apple IOS style guide. From what I can tell, the native desktop OS look and feel is going away. It won't be completely gone for a long time but my sense is that we will see far more weblike apps on the desktop then we will see desktop like apps on the browser. We could accelerate that process if we could use brython in WebKit. 

Right now, because of a personal project I am working on, I am in the process of creating a widget library. The style looks a bit like Qt widgets, though it is far from a publishable state. The interesting

part about it is, that I am using Django for server-side of the project and I've been able to implement stubs for some django classes so that, you can almost import your models as is into a Brython

application and access them in the browser, e.g. writing:

from widgets import DataListView
from myapp.models import Person


view = DataListView(Person.objects.all())


document['people'] <= view.elt



And have a nice list of all the people in your myapp_Person table show up on your page. 

Interesting. Personally I found the HTML/CSS UI model a shorter learning curve than any of the GUI toolkits. My experience with building PWA's with Brython is coming up with a very different model for expressing user interface elements.  This is a slightly reworked example from something I'm working on. It generates a card for display with a bunch of data elements on the card. Most of this could be handled by template except for the variable decorations. The only one in this example is called hy_styling.

The point behind this example is that it illustrates how building the UI elements from the inside out makes the most sense to my mind. It's probably obvious to everyone that I grew up programming on HP calculators and forth. :-)

def generate_card (card_name, card_data):

    card_register_inner = SPAN("devx {}".format(card_data["devx_id"])) + SPAN("value {}".format(card_data["devx_val"]))

    card_register_block = DIV(card_register_inner)

    card_action_inner = A("Scope drive on", href="!#") + A("Scope drive off", href="!#")

    card_action_block = DIV(card_action_inner, Class="card-action")

    last_reading_block = DIV("some placeholder")

    hy_styling = dict(style=dict(float="left"))

    data_inner_block = SPAN("point: ", style=dict(float="left")) + \

                       SPAN(card_data["devx_value"],  **hy_styling)

    data_block = DIV(data_inner_block)

    card_content_inner =  SPAN(card_data["devx_display_name"], Class="card-title") + \

                          card_register_block + \

                          last_reading_block + \

                          data_block + \

                          card_action_block

    card_content_block = DIV(card_content_inner, Class="card-content text-white")

    card_block = DIV(card_content_block, Class="card green lighten-3")

    return card_block

 I want to revisit this example and devise a DSL (domain specific language) that makes it easier to build up an interface and keep track of the things that can be changed without regenerating everything. Part of the idea behind the DSL is that it should be possible to build new DSL elements that are very specific to your application and are considered first-class elements akin to the native ones. As Jonathan pointed out, something like angular templates etc. I'm going to revisit my recursive template tool and see if there's anything in there I could build on for this application. 

One of the Brython tools/tricks that I haven't figured out yet is how intermingle HTML and browser.html module. Most of the code in the above example could have been static HTML and I just fill in a few blanks. There is no need to generate everything. The flip side of that trick is printing out the HTML the code generates so I can look over it and figure out why the hell is not doing what I thought it should.

I definitely think that is a good idea and I am sorry I missed the sprint. Being in Europe and having a day job there's no way i could've attended in person, but at least I could have been online :-(

I agree. I would like to participate some online/real-time chats with folks. IRC or IRC like tools will work fine.