Re: Python in the browser: Merge efforts into one project?

[Salvatore DI DIO]

Hello Amirouche,

For better adoption, i think it worths to get it self-hosted.

Look at RapydScript for exemple, it allows using command lline or self-hosting in the browser.

Here is a sample, i have published :

You can edit the code an run without server backend

http://salvatore.pythonanywhere.com/RapydBox/editor (browse with Firefox)

http://salvatore.pythonanywhere.com/RapydRay

or

http://pyjeon.pythonanywhere.com/static/rapydscript_online/index.html

It would be nice to have the equivalent with Pythonium 

 

 

 

Regards

[Dan Stromberg]

On Wed, Nov 20, 2013 at 4:25 AM, Amirouche Boubekki <amirouche...@gmail.com> wrote:

Héllo,

Pythonium [0] creator here. I write this email to ask the community what they think about merging the different efforts to have Python in the browser.

I think merging the various projects would be a very good thing - but I'm not going to hold my breath.

[Amirouche Boubekki]

Héllo,

Pythonium [0] creator here. I write this email to ask the community what they think about merging the different efforts to have Python in the browser.

What do you think about merging Python in the browser effort into one unique project?

What can prevent you from contributing to such a projects? Mind the fact, that I'm willing to change the license to a more liberal license (LGPLv3) if people come and contribute to the project.

Frankly, I think pythonium approach is superior to every other solutions. Anything other solution does, Pythonium can do, except it's faster.

If you don't know Pythonium, basicly current version use Python 3 ast parser to generate, fast javascript code unlike Brython and Skulpt and like pyjaco, pyjs pyjeon which is written in javascript. Unlike Brython and Skulpt which are self hosted.

Like I said, it can be self-hosted, but with proper tooling [1] we don't need that.

Also, I don't care about the name and we can take whatever name the community think is best.

So what's do you think?

Make sure to have pythoni...@googlegroups.com in the reponse header, so that other people can follow the conversation.

Best regards,


Amirouche

[0] https://github.com/pythonium/pythonium
[1] Integration with frameworks, compile server with inotify, backend side compilation

[Amirouche Boubekki]

2013/11/20 Ondřej Čertík <ondrej...@gmail.com>

On Wed, Nov 20, 2013 at 5:25 AM, Amirouche Boubekki
<amirouche...@gmail.com> wrote:

> Héllo,
>
>
> Pythonium [0] creator here. I write this email to ask the community what
> they think about merging the different efforts to have Python in the
> browser.
>
>
> What do you think about merging Python in the browser effort into one unique
> project?
>
>
> What can prevent you from contributing to such a projects? Mind the fact,
> that I'm willing to change the license to a more liberal license (LGPLv3) if
> people come and contribute to the project.

You should change it to BSD or Apache license.

I will consider BSD or Apache, also.

 

>
>
> Frankly, I think pythonium approach is superior to every other solutions.
> Anything other solution does, Pythonium can do, except it's faster.
>
> If you don't know Pythonium, basicly current version use Python 3 ast parser
> to generate, fast javascript code unlike Brython and Skulpt and like pyjaco,
> pyjs pyjeon which is written in javascript. Unlike Brython and Skulpt which
> are self hosted.
>
> Like I said, it can be self-hosted, but with proper tooling [1] we don't
> need that.
>
> Also, I don't care about the name and we can take whatever name the
> community think is best.
>
>
> So what's do you think?

You are welcome to reuse anything as you see fit. Do you plan to implement
all Python features eventually, or are you just trying to have a Python syntax,
but not necessarily the same behavior?

There will be three versions:

1) Core: only implement the same syntax and similar behavior: single inheritance, no __getattribute__, no __getattr__, Javascript types, it already available in the repository. Direct access to Javascript (no binding is necessary), special function new to call JS' new

2) Veloce: Still single inheritance, it use Python types, has __geattribute__ and __getattr__, no data descriptors, function as metaclasses, no __call__ will not be supported in this version

3) Compliant: Fully compliant

I do that because each time there is some more overhead. So people will be able to choose to start developping with the Compliant version while still having the benefit of being able to use Javascript libraries and later downgrade to Veloce or Core, while adpating the code for better performance.

Pythonium Core is already available.

Ondrej

>
>
> Make sure to have pythoni...@googlegroups.com in the reponse header, so
> that other people can follow the conversation.
>
>
> Best regards,
>
>
> Amirouche
>
>
>
> [0] https://github.com/pythonium/pythonium
> [1] Integration with frameworks, compile server with inotify, backend side
> compilation
>

> --
> You received this message because you are subscribed to the Google Groups

> "py2js mailinglist" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to py2js+un...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups "Pythonium users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pythonium-use...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Amirouche Boubekki]

First thanks for all of you, for taking the time to consider this project.

2013/11/20 Alexander Tsepkov <atse...@gmail.com>

Combining efforts together would definitely help the Python community as all of the projects have their strengths others could benefit from.

Agreed.

 

I'm already considering adding the optional arguments implementation you stated on github into RapydScript, for example (https://github.com/atsepkov/RapydScript/issues/5).

Unfortunately, most of the projects you mention have different design philosophies that would probably prevent such merge.

 

For example,

 

I can tell you right now that Pythonium's license terms would prevent at least several RapydScript developers from joining in. In a world where most frameworks/compilers have MIT/BSD licenses (think jQuery, CoffeeScript, etc.) a GPL variant stands no chance if you want new users to jump onboard. If you do in fact change the license , that point becomes irrelevant.

I propose to change the license.

 

Also, while skulpt and pyjamas try to emulate Python functionality 'exactly',

Pyjamas doesn't emulate exactly Python, Brython and Skulpt do.

 

RapydScript aims for performance inside the browser, and compatibility with native JavaScript.

Pythonium *Core* aims for the same goal.

 

There are parts of Python that RapydScript has no intention of adopting because JavaScript's alternatives it uses now are simply better. One example is anonymous functions instead of lambda.

In javascript anonymous function is a only a sugar syntax. It's the common idiom because that's available AFAIK only in JavaScript so it seems like a specialized for the Web syntax. Indeed it does makes sens, in simple situations, but not in big projects, it isn't.
When the code base grows you are better served by an object system even if you don't use prototype inheritance.
Anyway, the advent of yield in JavaScript will remove the need to use anonymous functions.

 

Additionally, you claim that a JavaScript-based compiler is a weakness rather than a strength.

It's weakness because the code is for Pythonista less readable and as such there will be less contributions.

 

I, and several other RapydScript developers (as you already saw from Salvatore's post) think otherwise. RapydScript compiler can run in a browse. Pythonium can't.

 

It's possible to make Pythonium work in the browser, Brett did it for PythonJS adapting Brython ast parser. Running in a browser is developer sugar. I don't see that as a major feature.

In production you want an ugly compiled version because that's what is fast and lightweight. That's why I started with that.

 

In fact, the original version of the compiler was written in Python as well, and I later rebuilt it using uglifyjs as a base in order to improve compilation speed, parsing power, and compatibility. There is already a JavaScript decompiler project (https://github.com/charleslaw/RapydScript-Decompiler) that we eventually plan to use to port our compiler into native RapydScript.

Nice.

 

With that said, I do believe both RapydScript and Pythonium can benefit greatly from each other. We're approaching the same problem from opposite directions, your AST structure is based on Python, ours is in JavaScript. This gives you the benefit of staying more pure to Python and us the benefit of being more compatible with native JS,

 

we can still share solutions with each other.

I understand you don't want to join the two projects. Fair enough, my strong point against RapydScript is that it is written in JavaScript. And this is not good for people to contribute. Pythonium is completely compatible with native JS. I hope we can come to a solution to share more.

 

You received this message because you are subscribed to the Google Groups "py2js mailinglist" group.

[Amirouche Boubekki]

On Tuesday, November 26, 2013 8:47:19 AM UTC+1, Dirk Krause wrote:

As far as I can see, the main author of Brython (Pierre, I think?) didn't respond to this request yet, so there is still a chance this might be happening.

:(
 

My two cents: I would love to see the two projects merge into a 'Brythonium' :-) (especially for effectiveness reasons).

Me too, I like the name name!
 

Yet I see that the different approaches might make it difficult to acchieve that easily.

Some thoughts:

1) I like that Brython does the translation on the fly at runtime for rapid development.

It's possible to do it also for Pythonium but I see it as a less useful feature than source map support.
 

2) Then again, I would also like to be able to do a pre-compilation like Pythonium does. For example, I would like to use the Yeoman workflow i.e., build Pythonium into the chain and be able to do minification etc.

3) I think it's imperative to be able to throw standard JavaScript libraries into the equation and bind them easily. The JSObject and JSConstructor functions are a good start here. I still have to figure out how to do that in Pythonium.

In Pythonium it's transparent, you can use javascript object just like Python objects. Only thing is the special function new(SomeConstructor, foo, bar, baz) is translated to new SomeConstructor(foo, bar, baz)
 

4) I have no idea if that is feasible, but if more targets could be supported that would be awesome. I am thinking about asm.js mainly.

There is AFAIK no interest in supporting asm.js more over it wouldn't be portable so I don't think it will be done.

As far as Pythonium is concerned, I changed the license to LGPLv2.1 and the compliant mode of Pythonium made good progress we can run pystone [1]

Next developpement will be:

- improve requirejs integration for proper use of “from spam import egg”
- asyncio integration

[1] https://groups.google.com/d/msg/pythonium-users/wv264TWdsTI/co5lJjjkvzYJ

[davidjensen]

I am all in favor of a robust Python replacement for JavaScript, even if some efforts were joined. Brython is impressive.

[damond...@gmail.com]

Hi there,

It would be great idea to join forces towards a unified open-source client-side web dev Python tool effort.

Best of all would be to integrate them with the server-side Python web frameworks support of a full stack IDE.

With the current big trend of JS web frameworks -- covering the whole design pattern spectrum from server-side MV* and as little ajax as possible to SPA client-side MV* and a simple ReST DB layer server -- is a bit worrying. I am the only one to think that the temptation to do everything in a single, dynamic language (albeit flawed but improving and backed by all giant corporations - Google, MS, Apple, Amazon you name it) will end up threatening the current popularity of server-side MV* Python frameworks such as django & web2py?

IMHO, if the Python web development community persists in supporting only one design pattern and requiring JS for the seemingly ever growing client-side part of the whole code, as wonderful and popular as they are now, these Python web frameworks are at risk to become fairly quickly a legacy approach like Silverlight and Flash have become.

So for better adoption of RapydScript, the missing killer features might be intellisense as a Visual Studio extension, integration with the web2py web IDE etc.

Concerning Visual Studio, since JS and JQuery intellisense are already available, and so is Python and Django intellisense with the free open-source Python Tools for Visual Studio (PTVS) extension, it appears that it would only require reusing the two and gluing them into a coherent whole. From my limited understanding, it seems however that Visual Studio extensions can only be implemented in C# & VB and not in another .Net languages such as IronPython, which is a hindrance for getting pythonistas involved.

Just my noob 2 cents, regards

[Amirouche Boubekki]

On Monday, December 16, 2013 11:22:16 PM UTC+1, davidjensen wrote:

I am all in favor of a robust Python replacement for JavaScript, even if some efforts were joined. Brython is impressive.

What is impressive in Brython?

[David Holmes]

While the idea of merging Python implementations sounds good from an efficiency perspective, I rather think that the combination of technical challenge and effort would make this prohibitive. My assumption is that the various Python representations are different in a way that directly reflects their design goals and implementation and manifests in their properties. Some implementations pay more attention to Python standards, others to JavaScript interoperability, others to performance. The only way that I see of having common code would be to have some kind of meta-project that could generate implementations with different characteristics. Open source projects tend to reflect the cost/benefit balance i.e., it only happens if someone wants it so badly that they are prepared to put in the sweat. So maybe this will happen somewhere in the universe but I doubt we will see it in my lifetime.

Sorry to rain on your parade. I hate to kill the joy.

I'm just the old guy. Best Wishes.

David

--
 
---
You received this message because you are subscribed to the Google Groups "Skulpt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skulpt+un...@googlegroups.com.

[Amirouche Boubekki]

2014-02-16 18:54 GMT+01:00 David Holmes <david.ge...@gmail.com>:
> While the idea of merging Python implementations sounds good from an
> efficiency perspective,

Agreed.

> I rather think that the combination of technical
> challenge and effort would make this prohibitive.
> My assumption is that the
> various Python representations are different in a way that directly reflects
> their design goals and implementation and manifests in their properties.

Yet, those properties are the same, Pythonium can do everything other
Python->JS does or wants to do.

> Some implementations pay more attention to Python standards, others to
> JavaScript interoperability, others to performance.

AFAIK Pythonium does it all.

> The only way that I see
> of having common code would be to have some kind of meta-project that could
> generate implementations with different characteristics.

That is an optimisation step. Not very required. But anyway, you would
need to have
a python that run on top of JavaScript VM to do that. Python is a
better representation that
javascript, if you ever need to manipulate code to generate code you
would want to do it
in Python, not Javascript and not Python that manipulates Javascript...

> Open source
> projects tend to reflect the cost/benefit balance i.e., it only happens if
> someone wants it so badly that they are prepared to put in the sweat.

Merging the project will have a direct impact on cost + benefits in a good way.

> So
> maybe this will happen somewhere in the universe but I doubt we will see it
> in my lifetime.

Do not be that guy.

> Sorry to rain on your parade.

No parade here :)

> I hate to kill the joy.

You did not kill any joy [1].

> I'm just the old guy.

If the old could, if the new knew...


To sum up my point of view regarding this topic of merging efforts,
the only thing I see, is
that people have bet on solutions and want to stay king in their
kingdom. This is not technical
debate, it's purely political.

By the way I stop further development of Pythonium for the time being,
I have no immediate
interest in this topic anymore. I just wanted to see if it was
possible, and do few checks regarding
politic in the computer industry. Pythonium Veloce is working and
kicking all I wanted, getting Pythonium
Compliant is AFAIK just a matter of getting the code written.

Best Wishes,

Amirouche

> Best Wishes.
> David
>
>
> On Sun, Feb 16, 2014 at 11:02 AM, Amirouche Boubekki
> <amirouche...@gmail.com> wrote:
>>
>>
>>
>> On Monday, December 16, 2013 11:22:16 PM UTC+1, davidjensen wrote:
>>>
>>> I am all in favor of a robust Python replacement for JavaScript, even if
>>> some efforts were joined. Brython is impressive.
>>
>>
>> What is impressive in Brython?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Skulpt" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to skulpt+un...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups

> "Pythonium users" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to pythonium-use...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

[1] http://en.wikipedia.org/wiki/Joy_%28programming_language%29