Re: Help finding right place for my questions

Great. Thank you so much for sharing your thoughts. I'd really like to
spend my time researching something that will be useful to people, and
contribute something to the Python community. I'd hate to have the work I
do in grad school get filed away somewhere as a purely academic exercise.

On Sun, Nov 10, 2019, 2:36 PM Bobby Holley <[email protected]> wrote:

> On Sun, Nov 10, 2019 at 12:59 PM yun bao <[email protected]> wrote:
>
>> I glanced at Pyodide the other day, but just took a closer look.  It's an
>> awesome project.  Thanks for the tip.  I've reached out on their Gitter
>> channel.
>>
>> I figured that the additional size, complexity, etc., that may result by
>> getting Python running in a browser would cause web browser developers to
>> be understandably reluctant to integrate it.  On the other hand, I think
>> the first browser to do it will immediately win a huge following of Python
>> developers, as it seems that a lot of Python developers don't care much for
>> JavaScript.
>>
>> It sounds like you're saying that the only way mainstream integration and
>> support of Python in the browser will happen is by implementing it in a way
>> that minimally impacts the existing architecture of web browsers.  Is that
>> accurate?  Developers will need to find a way to work with the existing web
>> technologies (even newer ones like WebAssembly), rather than introduce
>> something that fundamentally changes how web browsers work?
>>
>
> Yes. The question of whether Python should be a first-class language in
> the browser was debated about a decade ago, and the consensus answer among
> browser vendors was that it should not.
>
> However, that doesn't mean the answer is that everyone needs to use
> Javascript. WebAssembly is intended to be programming-language-agnostic -
> you can compile lots of things to WebAssembly, and then run them in the
> browser. This opens up lots of interesting possibilities, which are being
> explored by projects like Pyodide. WebAssembly itself is also evolving and
> growing new capabilities in response to the things people are doing with
> it. There's a huge amount of potential for interesting research in that
> space, whereas trying to bolt Python directly into a browser engine is
> almost certainly a dead-end.
>
> bholley
>
>
>>
>> On Sun, Nov 10, 2019 at 11:06 AM Bobby Holley <[email protected]>
>> wrote:
>>
>>> I would suggest having a look at Pyodide for prior art in this space:
>>> https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/
>>>
>>> I'm going to assert that the future of python in the browser will
>>> involve targeting WebAssembly, rather than any bespoke python hooks in the
>>> browser engine (the chances of us or any other browser engine accepting
>>> patches for python integration are extremely low). I would highly suggest
>>> orienting your research towards WebAssembly, which is a very promising
>>> technology with substantial runway for new research.
>>>
>>> bholley
>>>
>>> On Sun, Nov 10, 2019 at 10:33 AM yun bao <[email protected]> wrote:
>>>
>>>> I'm still in the initial information gathering phase of my thesis.  So I
>>>> expect my thesis idea (which is admittedly rather vague at this point)
>>>> to
>>>> change a lot as I learn more about the domain.  However, as I'm
>>>> applying to
>>>> a graduate program outside of my home country, the application deadline
>>>> is
>>>> December 1st.  So, I don't have a lot of time to refine the idea.
>>>>
>>>> My original idea was to use as little JavaScript as possible.  At a bare
>>>> minimum, I envision not needing to translate Python to JavaScript in
>>>> some
>>>> way, which is how most projects I've seen have managed to get Python
>>>> running in a browser.  The long term goal is having a Python engine
>>>> running
>>>> in a web browser.  So, Python is actually executed as Python (or
>>>> whatever
>>>> Python is normally executed as under the hood), and not subjected to
>>>> some
>>>> convoluted process that turns it into JavaScript.
>>>>
>>>> I'm thinking the best Python implementation for use in a browser would
>>>> be
>>>> PyPy, since it uses JIT compilation.  I'm not sure that the whole of the
>>>> Python standard library will ever be available for use in a browser,
>>>> though.  I think, as a proof of concept, just getting a Python engine
>>>> running in a browser, even if only a small subset of the standard
>>>> library
>>>> is available, and playing nice with a rendering/layout engine, would be
>>>> a
>>>> kind of success.
>>>>
>>>> The PyPy folks are currently working on sandboxing PyPy (
>>>> https://pypy.readthedocs.io/en/latest/sandbox.html).  It seems like
>>>> there
>>>> might be a few research opportunities just in the security related
>>>> aspects
>>>> of running Python in a browser.
>>>>
>>>> Thank you for your input, Boris.  If you, or anyone else, have any more
>>>> information or advice to share, I'd love to hear it.
>>>>
>>>> Andrew
>>>>
>>>> On Sat, Nov 9, 2019 at 9:55 PM Boris Zbarsky <[email protected]> wrote:
>>>>
>>>> > On 11/9/19 4:16 PM, yun bao wrote:
>>>> > > Right now I'm trying to better understand the general domain and
>>>> > discover if any
>>>> > > there are any well known problems related to making a Python web
>>>> browser
>>>> > > engine.
>>>> >
>>>> > Are you planning to do _just_ Python, or both Python and JavaScript?
>>>> >
>>>> > In the latter case, there is one well-known problem: preventing leaks
>>>> > due to circular object graphs that span both the JS and Python heaps,
>>>> > because the JS garbage collector does not know about the Python side
>>>> and
>>>> > vice versa.  This was a significant problem for PyXPCOM before we
>>>> > removed it.
>>>> >
>>>> > In both cases, there is the issue that the core Python language is not
>>>> > really what anyone thinks of as "using Python"; people tend to assume
>>>> > that with the language comes the standard library.  And the Python
>>>> > standard library doesn't really have concepts of sandboxing, origins,
>>>> > etc, that the web browser environment relies on for safety.  This
>>>> means
>>>> > that exposing parts of the standard library without introducing
>>>> security
>>>> > holes might be complicated, depending on your threat model.
>>>> >
>>>> > There are also various practical issues in terms of the browser
>>>> > internals assuming that objects have JS representations, parts of web
>>>> > APIs actually being very JS-specific (typed arrays, Promises, etc),
>>>> and
>>>> > other JS dependencies, but the above are the two big conceptual
>>>> problems
>>>> > I know of that people haven't really found solutions for in the past.
>>>> >
>>>> > -Boris
>>>> > _______________________________________________
>>>> > dev-tech-js-engine mailing list
>>>> > [email protected]
>>>> > https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>> >
>>>> _______________________________________________
>>>> dev-tech-js-engine mailing list
>>>> [email protected]
>>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>>>
>>>