Join efforts with brython and pyjs

[sametmax]

I would love to have a fairly complete JS implementation of the Python language, but for now all 3 major projects split the efforts in 3 directions.

You should team up guys, things would go faster. You'll have better exposure. And more tests, more bugs discovered. A better doc.

brython : http://www.brython.info/
pyjs : http://pyjs.org/

[bnmnetp]

Thanks for the comment.

First I would like to ask you to clarify a bit. You say you would love to have a fairly complete JS implementation of the Python language. In my view Skulpt is fairly complete. A few of us use Skulpt to teach Python and introductory computer science to thousands of people. So, what in your view is missing?

I've looked at brython off and on over the last few years, and I think they are doing good work, but our goals are pretty different. They say in several places that: "Brython is designed to replace Javascript as the scripting language for the Web." Thats a great goal, and maybe they will succeed but I think its an uphill battle.

I think our goals are more around creating a great implementation of Python that can be embedded in web based development environments and used in education.

I think both projects do some things better than others. Skulpt has a pretty decent implementation of Long ints, brython does not. In keeping with their goals, brython has done a lot of work around the DOM, and we have done fairly minimal work there... I note that brython now does have the ability to import modules, this was not the case a while ago, and so was a non-starter for me in I needed to have modules like turtle graphics and image processing to use in teaching. It would be interesting to make a list that carefully compares the features of the two.

Its easy to say "just merge your efforts", but that is a HUGE amount of work. Who decides what parts of each project stay and what parts go? In the short term it seems we both spend a lot of precious time redoing things that already work for the sake of joining forces. Maybe there is a group of people who are interested in doing that. If so, Great! But for myself the short term is the time when I am working on adding new features to skulpt in preparation for next fall.

I was curious about the response from the brython developers, but I notice that you did not file a similar issue on their bitbucket site. Why not?

[david-geo-holmes]

Thanks for your interest and suggestion. The idea certainly merits some
thought. Here is my two cents and experiences.

Based upon my extensive experience working with Skulpt, my own fork, and
looking at other approaches I have learned that this problem is an
engineering task - meaning it has tradeoffs.

The biggest tradeoff by far is compliance versus performance. This arises
mostly due to the different scoping rules in Python and JavaScript. More
Python-compliant implementations, like Skulpt, generate lots of code to
make this happen. Others keep the code light but use JavaScript scoping
rules.

The second biggest tradeoff could be the user experience (friendliness)
versus performance. For example, Skulpt maintains source locations in the
compiled JavaScript, while other implementations may not or may use
external source maps and evaluate the code differently. Skulpt is optimized
in the direction of friendliness which is good for pedagogy and education.

Operator overloading is another issue. This cannot be done selectively in a
non-statically typed language like JavaScript and so if you want to do it
you pay a cost - always. Skulpt aims for Python compliance and so takes the
hit. I've seen other implementations debating the issue and even offering
choices.

I've also been tinkering with operator precedence in my own fork in order
to support a mathematical language called Geometric Algebra. Supporting
Python compliance and custom precedence at the same time would require
different lexers.

And then there are technical issues affecting the implementation and its
consumption. Im talking here about the Google Closure compiler, whether to
use require.js, and similar issues.

Taking all these issues into account, and considering the consequences of a
monoculture, I'm inclined to believe that diversity is a good thing for
progress.

Cheers,

David

On Wed, Jun 18, 2014 at 2:51 AM, sametmax notifications@github.com wrote:

I would love to have a fairly complete JS implementation of the Python
language, but for now all 3 major projects split the efforts in 3
directions.

You should team up guys, things would go faster. You'll have better
exposure.

—
Reply to this email directly or view it on GitHub
#246.

[sametmax]

Hello,

I'm sorry if I came out too strong. You are doing an awesome job and I did sound a bit duchy.

First I would like to ask you to clarify a bit. You say you would love to have a fairly complete JS implementation of the Python language. In my view Skulpt is fairly complete. A few of us use Skulpt to teach Python and introductory computer science to thousands of people. So, what in your view is missing?

Ok. I am a Python trainer myself, so I wanted to test it to see what I could do with it.

First, I tried a hard stuff.

class A(object):
    message = 'a'
    def test(self):
        print('a>' + self.__class__.__name__)

class B(object):
    def test(self):
        print('b>' + self.__class__.__name__)

class C(A, B):
    def test(self):
        A.test(self)
        B.test(self)

C().test()

Expected result:

a>C
b>C

Got:

AttributeError: 'C' object has no attribute 'name' on line 4

Ok, fair enough. Multiple inheritance is hard. Implementing it in JS is not something I'd like to have on my plate.

So I tried some implementation details, still hard, but accessible to implement in JS :

iter([])

Got not implemented yet.

(x for x in range(0)).next() 

Should raise StopIteration but silently does nothing.

Right. So I can't do advanced training with it, but maybe I can do intermediate training.

So I gave a shot to :

class Context(object):
     def __enter__(*args, **kwargs):
          print("Enter")
     def __exit__(*args, **kwargs):
          print("exit")

with Context():
     print('test')

Expecting :

enter
test
exit

But I got a silent error (nothing in Firefox console, using FF 30 on Ubuntu 14.04 64bits)

Gave it a second shot :

def decorate(func):
     print(func)

@decorate
def test():
     print('test')

Expecting <function test at 0x7fb134b78758>

Bur got another silent error.

Well, maybe I can do beginer trainings :

import datetime
print(datetime.datetime.now())

ImportError: No module named datetime on line 1

You advertise implementing Python, not all stdlib. Fair enough.

I tried format(), but realized it was Python 2.6. Really old for my trainings, but updating to 2.7 is hard, since there is a lot of backported features from Python 3.

Ok, so maybe just very basic stuff from Python 2.6 builtins should do ?

print([1, 2][True])

TypeError: list indices must be integers, not bool on line 1

print(set((1,2,3)) & set((2, 3, 4)))

TypeError: unsupported operand type(s) for BitAnd: 'set' and 'set' on line 1

After that, I gave up. I just can't use it for anything : not programming, not training.

Now I am certainly not saying you did a bad job. You did a f***ing incredible jobs going that far (lambdas and generators work !).

But this is miles away from being a complete Python implementation.

I've looked at brython off and on over the last few years, and I think they are doing good work, but our goals are pretty different. They say in several places that: "Brython is designed to replace Javascript as the scripting language for the Web." Thats a great goal, and maybe they will succeed but I think its an uphill battle.

Probably yeah.

I think our goals are more around creating a great implementation of Python that can be embedded in web based development environments and used in education.

I'm all for that. I wrote literally more than 300 articles and tutorials related to Python during the last 2 years. Having a good implementation to demonstrate the stuff online would be genius. I never found one.

I think both projects do some things better than others. Skulpt has a pretty decent implementation of Long ints, brython does not. In keeping with their goals, brython has done a lot of work around the DOM, and we have done fairly minimal work there... I note that brython now does have the ability to import modules, this was not the case a while ago, and so was a non-starter for me in I needed to have modules like turtle graphics and image processing to use in teaching. It would be interesting to make a list that carefully compares the features of the two.

Its easy to say "just merge your efforts", but that is a HUGE amount of work. Who decides what parts of each project stay and what parts go? In the short term it seems we both spend a lot of precious time redoing things that already work for the sake of joining forces.

Yeah, I apologize for that. I was a dick saying that. It's a enormous work.

Maybe there is a group of people who are interested in doing that. If so, Great! But for myself the short term is the time when I am working on adding new features to skulpt in preparation for next fall.

I would be, except I'm already involved in several FOSS projects (the last one being http://tavendo.com/blog/post/is-crossbar-the-future-of-python-web-apps/) and I can spend more time on anything else.

And it's very hard to find motivated, skilled, available contributors.

I was curious about the response from the brython developers, but I notice that you did not file a similar issue on their bitbucket site. Why not?

I fucked up. It was an emotional reaction. I was reading an article on reddit about you, and though "WTF, another Python JS implementation ?", so I instant wrote that issue. Shouldn't have done that.

Thanks for your interest and suggestion. The idea certainly merits some
thought. Here is my two cents and experiences.

Based upon my extensive experience working with Skulpt, my own fork, and
looking at other approaches I have learned that this problem is an
engineering task - meaning it has tradeoffs.

The biggest tradeoff by far is compliance versus performance. This arises
mostly due to the different scoping rules in Python and JavaScript. More
Python-compliant implementations, like Skulpt, generate lots of code to
make this happen. Others keep the code light but use JavaScript scoping
rules.

Yeah, I figured. The messy JS scope and the prototypal inheritance make it very hard to hack something like that.

The second biggest tradeoff could be the user experience (friendliness)
versus performance. For example, Skulpt maintains source locations in the
compiled JavaScript, while other implementations may not or may use
external source maps and evaluate the code differently. Skulpt is optimized
in the direction of friendliness which is good for pedagogy and education.

Operator overloading is another issue. This cannot be done selectively in a
non-statically typed language like JavaScript and so if you want to do it
you pay a cost - always. Skulpt aims for Python compliance and so takes the
hit. I've seen other implementations debating the issue and even offering
choices.

Or, hence the set() & set() error. Got it.

I've also been tinkering with operator precedence in my own fork in order
to support a mathematical language called Geometric Algebra. Supporting
Python compliance and custom precedence at the same time would require
different lexers.

And then there are technical issues affecting the implementation and its
consumption. Im talking here about the Google Closure compiler, whether to
use require.js, and similar issues.

Taking all these issues into account, and considering the consequences of a
monoculture, I'm inclined to believe that diversity is a good thing for
progress.

Depends. It drives innovation, but reduce stability and completeness. Right now, there are 3 competing implementations, all doing ok in some areas and not in others, make them all nice but not really usable.

But I got it, easy to talk, better to PR, which I don't have the time to do. So I'll shut up.

Thanks a lot for taking a lot of time to answer with such details.

Good luck with the project.

I'll make sure I'll mention it to people looking for such a tool.

[ebertmi]

Well in the README are some of the problems described and what is working and what not. However the name problem is fixed here: ebertmi@ad3767f
Currently I am working on the time module: https://github.com/waywaaard/skulpt/blob/pr_time/src/lib/time/__init__.js
Which already supports most of the functions.

And regarding to Python 2.7 see this PR: #201

As you can see there are enough efforts and contributions to this, however it is not an easy task. Notably, that we trying to cover most aspects with tests.

[bnmnetp]

Good examples. I can see why you were not happy.

So, the lack of error messages on skulpt.org is a silly longstanding bug, that we are going to fix. They are there, we just aren't showing them on the site. Maybe today.

For the other problems, I would say that these are exactly the kind of test cases and examples we like to see. The bugs that I fix, and the enhancements that I make to skulpt are usually the one's that crop up when when I find something I would like to teach. So I would encourage you to file those as separate issues. I don't think some of them are as bad as they look.

Although I'm not sure I would ever teach print([1,2][True]) to my CS1 or CS2 students.

Brad

[sametmax]

Although I'm not sure I would ever teach print([1,2][True]) to my CS1 or CS2 students.

It's very useful to explain ducktyping.

[albertjan]

@waywaaard you're on fire 😄

[eah13]

I've been educating myself on old open issues and thought I'd reference #49 as relevant to this discussion: maybe support for brython-style <script type="text/python"> could be an intermediate step towards more compatibility?