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.
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 .
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
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 ?
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 BrythonIn 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, ...) .
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 BrythonIn 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 .
- 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
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 greatI'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'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.
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 ?
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.
If you are interested in this work, I should write blog post about it soon.
Regards
Goffi
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
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/autobahnA common subject in MicroPython talks , btw .
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 ?
@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
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 .
- 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 would try to be independent from css/js libs/frameworks (they come and go very fast and why one over others).
from widgets import DataListView
from myapp.models import Person
view = DataListView(Person.objects.all())
document['people'] <= view.elt
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 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 interestingpart 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 Brythonapplication 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.eltAnd have a nice list of all the people in your myapp_Person table show up on your page.
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 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 :-(