Python to JavaScript: Excessive parentheses, tuple unpacking

[Jonathan Fine]

Hi

Here's a couple of problems. 

(1) As present, at least one of the py -> js produces JavaScript with excess parentheses.  This reduces readability.

(2). I'd expect "a, b = 1, 2" to produce "a = 1; b = 2", possibly with var declarations.  I get something more complcated and, more important, the var declarations are missed off.

I know the bug in (2) can be fixed with some work, but how can we be sure that there are no other similar bug lurking in the code?


py2js-github$ python -i py2js.py
Usage: py2js.py [options] filename

Python to JavaScript compiler.

Options:
  -h, --help          show this help message and exit
  --include-builtins  include py-builtins.js library in the output
>>> convert_py2js('1+a')
'(1)+(a);'
>>> convert_py2js('a, b = 3, 4;')
'var __dummy0__ = tuple([3, 4]);\na = __dummy0__.__getitem__(0);\nb = __dummy0__.__getitem__(1);'
>>> convert_py2js('a =1 ; b = 2')
'var a = 1;\nvar b = 2;'
>>>

--
Jonathan

--
You received this message because you are subscribed to the Google Groups "JavaScript for Python programmers" group.
To post to this group, send an email to js...@googlegroups.com.
To unsubscribe from this group, send email to js4py+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/js4py?hl=en-GB.

[Ondrej Certik]

On Sat, May 8, 2010 at 9:36 AM, Jonathan Fine
<jonatha...@googlemail.com> wrote:
> Hi
>
> Here's a couple of problems.
>
> (1) As present, at least one of the py -> js produces JavaScript with excess
> parentheses.  This reduces readability.
>
> (2). I'd expect "a, b = 1, 2" to produce "a = 1; b = 2", possibly with var
> declarations.  I get something more complcated and, more important, the var
> declarations are missed off.
>
> I know the bug in (2) can be fixed with some work, but how can we be sure
> that there are no other similar bug lurking in the code?

It's not a bug. In general, you need to use tuples to unpack things,
imagine this code:

a, b = some_tuple

I don't think that this can be optimized anyhow. What do you think?

However, I agree that for simple cases, it can be optimized to
generate some simpler code. I am very busy, so I just want to make
sure that the general case works and that all tests pass. Later on, we
can optimize it.

Ondrej

[Jonathan Fine]

On Sat, May 8, 2010 at 5:57 PM, Ondrej Certik <ond...@certik.cz> wrote:

On Sat, May 8, 2010 at 9:36 AM, Jonathan Fine
<jonatha...@googlemail.com> wrote:
> Hi
>
> Here's a couple of problems.
>
> (1) As present, at least one of the py -> js produces JavaScript with excess
> parentheses.  This reduces readability.
>
> (2). I'd expect "a, b = 1, 2" to produce "a = 1; b = 2", possibly with var
> declarations.  I get something more complcated and, more important, the var
> declarations are missed off.
>
> I know the bug in (2) can be fixed with some work, but how can we be sure
> that there are no other similar bug lurking in the code?

It's not a bug. In general, you need to use tuples to unpack things,
imagine this code:

a, b = some_tuple

I don't think that this can be optimized anyhow. What do you think?

However, I agree that for simple cases, it can be optimized to
generate some simpler code. I am very busy, so I just want to make
sure that the general case works and that all tests pass. Later on, we
can optimize it.

I'd like to be sure that the architecture will support such optimisations.

Regarding the bug, perhaps I wasn't clear enough.  The bug is that we don't get the 'var' declarations.

>>> print convert_py2js('def f(): a, b = [1, 2]')
function f() {
    var __dummy0__ = list([1, 2]);
    a = __dummy0__.__getitem__(0);
    b = __dummy0__.__getitem__(1);
}

>>> print convert_py2js('def f(): a =1; b = 1')
function f() {
    var a = 1;
    var b = 1;
}

--
Jonathan

[Ondrej Certik]

On Sat, May 8, 2010 at 10:44 AM, Jonathan Fine

I think so. You just check the right hand side and the left hand side
and if it's some simple integers, you emit a simpler code.

>
> Regarding the bug, perhaps I wasn't clear enough.  The bug is that we don't
> get the 'var' declarations.

Ah, right! Thanks for finding this out. I need to write a test for
this, that fails and then I'll fix it.

Ondrej

[Ondrej Certik]

I wrote a test for this and a fix in this patch:

http://github.com/mattpap/py2js/commit/3b0c22047962bc9e2692ba3b993bb81641d297a0

and to answer your question to make sure that there are no more bugs
like this --- the only way is to have extensive tests and just keep
improving the tests.

[Ondrej Certik]

On Sat, May 8, 2010 at 10:44 AM, Jonathan Fine

So this is how it looks like now:

In [2]: print convert_py2js('def f(): a, b = [1, 2]')
------> print(convert_py2js('def f(): a, b = [1, 2]'))
var f = $def({}, function() {

var __dummy0__ = list([1, 2]);

var a = __dummy0__.__getitem__(0);
var b = __dummy0__.__getitem__(1);
});


In [5]: print convert_py2js('def f(): global a; a, b = [1, 2]')
------> print(convert_py2js('def f(): global a; a, b = [1, 2]'))
var f = $def({}, function() {

var __dummy0__ = list([1, 2]);
a = __dummy0__.__getitem__(0);

var b = __dummy0__.__getitem__(1);
});


Ondrej

[Peter Rust]

Ondrej,

A good way to test the functionality, rather than the exact syntax, in the
spirit of Niall's tests, would be to iterate the window/global object before
and after and verify that the code didn't introduce new globals.

For instance, this:

function f() {
var __dummy0__ = list([1, 2]);
a = __dummy0__.__getitem__(0);
b = __dummy0__.__getitem__(1);
}

creates window['a'] and window['b'] (might be "global" instead of "window"
in console-based javascript), whereas this:

function f() {
var a = 1;
var b = 1;
}

does not clutter the global namespace.

-- peter

[Ondrej Certik]

On Mon, May 10, 2010 at 9:56 AM, Peter Rust <pe...@cornerstonenw.com> wrote:
> Ondrej,
>
> A good way to test the functionality, rather than the exact syntax, in the
> spirit of Niall's tests, would be to iterate the window/global object before
> and after and verify that the code didn't introduce new globals.
>
> For instance, this:
> function f() {
>    var __dummy0__ = list([1, 2]);
>    a = __dummy0__.__getitem__(0);
>    b = __dummy0__.__getitem__(1);
> }
>
> creates window['a'] and window['b'] (might be "global" instead of "window"
> in console-based javascript), whereas this:
> function f() {
>    var a = 1;
>    var b = 1;
> }
>
> does not clutter the global namespace.

That's right. But, still it's kind of messy, as this would need some
special code for JS. Is there anything wrong with my test here:

http://github.com/mattpap/py2js/commit/3b0c22047962bc9e2692ba3b993bb81641d297a0

I believe that it tests exactly this, and it only tests the functionality.

[Peter Rust]

Ondrej,

> Is there anything wrong with my test here

Not at all -- that's a very cool way to test the functionality w/out the
syntax. I had written the previous email as a helpful implementation idea
before I read in your more recent email that you had already implemented it.
It looks great!

-- peter

-----Original Message-----
From: js...@googlegroups.com [mailto:js...@googlegroups.com] On Behalf Of
Ondrej Certik
Sent: Monday, May 10, 2010 10:13 AM
To: js...@googlegroups.com
Subject: Re: Python to JavaScript: Excessive parentheses, tuple unpacking

[Ondrej Certik]

On Mon, May 10, 2010 at 10:35 AM, Peter Rust <pe...@cornerstonenw.com> wrote:
> Ondrej,
>

>> Is there anything wrong with my test here
> Not at all -- that's a very cool way to test the functionality w/out the
> syntax. I had written the previous email as a helpful implementation idea
> before I read in your more recent email that you had already implemented it.
> It looks great!

Cool. Btw, I now use a $def function from the PJs project that you
discovered, Jared changed the license from GPL to MIT, so we can just
use it.

It makes the code a bit more complex yet again, e.g. notice the $def
above. But a bonus is that *kwargs and *args work quite nice now (it's
still not perfect, some more support for it is needed in py2js). But
it was trivial for me to use it in py2js, so I really like the
approach that we are taking (lightweight py2js converter and a solid
JS library).

[Ondrej Certik]

On Mon, May 10, 2010 at 11:25 AM, Ondrej Certik <ond...@certik.cz> wrote:
> On Mon, May 10, 2010 at 10:35 AM, Peter Rust <pe...@cornerstonenw.com> wrote:
>> Ondrej,
>>
>>> Is there anything wrong with my test here
>> Not at all -- that's a very cool way to test the functionality w/out the
>> syntax. I had written the previous email as a helpful implementation idea
>> before I read in your more recent email that you had already implemented it.
>> It looks great!
>
> Cool. Btw, I now use a $def function from the PJs project that you
> discovered, Jared changed the license from GPL to MIT, so we can just
> use it.
>
> It makes the code a bit more complex yet again, e.g. notice the $def
> above. But a bonus is that *kwargs and *args work quite nice now (it's
> still not perfect, some more support for it is needed in py2js). But
> it was trivial for me to use it in py2js, so I really like the
> approach that we are taking (lightweight py2js converter and a solid
> JS library).

And again, as usual there is a room for optimization -- if there are
no kwargs, the py2js can emit a regular JS function, without $def.

[Peter Rust]

> Jared changed the license from GPL to MIT, so we can just
> use it

That's great! So... you've been in contact w/ Jared? Is he interested in
py2js?

-- peter

-----Original Message-----
From: js...@googlegroups.com [mailto:js...@googlegroups.com] On Behalf Of
Ondrej Certik
Sent: Monday, May 10, 2010 11:26 AM
To: js...@googlegroups.com
Subject: Re: Python to JavaScript: Excessive parentheses, tuple unpacking

[Ondrej Certik]

On Mon, May 10, 2010 at 11:55 AM, Peter Rust <pe...@cornerstonenw.com> wrote:
>> Jared changed the license from GPL to MIT, so we can just
>> use it
> That's great! So... you've been in contact w/ Jared? Is he interested in
> py2js?

I only communicated with him here in the comments:

http://jaredforsyth.com/projects/pjs/#disqus_thread

[Jonathan Fine]

On Mon, May 10, 2010 at 5:56 PM, Peter Rust <pe...@cornerstonenw.com> wrote:

Ondrej,

A good way to test the functionality, rather than the exact syntax, in the
spirit of Niall's tests, would be to iterate the window/global object before
and after and verify that the code didn't introduce new globals.

I think this would be a useful tool, and I'd like it to be a standard part of tests.

--
Jonathan

[Nick Fitzgerald]

The CommonJS unit testing spec requires a test like this, if I remember correctly. I know that Narwhal, does at least.

Check out lines 81 through 97 of this file:

http://github.com/280north/narwhal/blob/d515f72ae5fbba0668bf7b0bf91eb7ffeed3e96f/lib/test.js

_Nick_

[Jonathan Fine]

That's good.  Looking at the file, I though "Here's an example of the sort of output a Python to JavaScript translator should be able to produce".

Jonathan

On Mon, May 10, 2010 at 10:58 PM, Nick Fitzgerald <fit...@gmail.com> wrote:

The CommonJS unit testing spec requires a test like this, if I remember correctly. I know that Narwhal, does at least.

Check out lines 81 through 97 of this file:

http://github.com/280north/narwhal/blob/d515f72ae5fbba0668bf7b0bf91eb7ffeed3e96f/lib/test.js

_Nick_

On Mon, May 10, 2010 at 2:08 PM, Jonathan Fine <jonatha...@googlemail.com> wrote:

On Mon, May 10, 2010 at 5:56 PM, Peter Rust <pe...@cornerstonenw.com> wrote:

Ondrej,

A good way to test the functionality, rather than the exact syntax, in the
spirit of Niall's tests, would be to iterate the window/global object before
and after and verify that the code didn't introduce new globals.

I think this would be a useful tool, and I'd like it to be a standard part of tests.

--