py2js: merge libraries?

[Peter Rust]

Also for posterity and so Ondrej can reply on-list, here is the email I sent this afternoon.

-- peter

-----Original Message-----
From: Peter Rust [mailto:pe...@cornerstonenw.com]
Sent: Thursday, April 29, 2010 1:09 PM
To: 'Ondrej Certik'
Subject: RE: Notification: py2js

Ondrej,

If it's trivial, I would like to try http://hg-git.github.com/ -- a co-worker here has been using it and it's been working well for him. There are a number of pythonistas using hg (my naïve impression is that the python community is currently split between hg and git with neither side having over 80%), so if it's trivial, it would be great to support both. If it becomes a problem or starts getting in our way, we can just go fully to git.

Thanks for your other email, good stuff. How about we rename the javascript library to "py-builtins.js" and subtitle it "Python Builtins for Javascript" and refer to it in code with an underscore as "py_builtins"?

I'm tempted to have the javascript library in a separate repository, as it can be used standalone and will have separate documentation and separate tests. The problem with this is when certain versions of py2js emit code for certain versions of py-builtins.js. I have mixed feelings. I think 90% of the API between the two can be completed within the next week or two (but things always take twice as along as I estimate :). Once the API settles down, I think it would make sense to have them in separate repositories -- and right now, since both are under such active development (alpha stage), I don't know that we need to expend a lot of energy right now keeping them in sync and recording which versions of py2js depend on which versions of py-builtins.js... what do you think?

Your idea (6b) of an option to generate code that doesn't depend on the JS lib at all is a good one. Something similar had crossed my mind, in fact, this is exactly what one of the guys in our local python group (http://github.com/fitzgen) wants from the project. He wants to write in Python syntax, but with Javascript built-ins, like "arr.push()" instead of "lst.append()". So it would be strictly a syntax converter. I don't want to expend a lot of energy on this, but it's actually more trivial than what we're doing now and shouldn't be too hard to implement/maintain alongside the lib-dependent code.

This actually goes along with the idea of a ff3 switch, but they would be different switches because they could be combined -- i.e. there are four possible combinations with the two switches.

I'm thinking the one switch could be called "language" and could be set to "js-1.8" but would default to "ecma-3" (later someone may want to add support for js-1.6, js-1.7, ecma-6 or ecma-5). The other switch could be called "js_lib_dependent" and could just be True or False (defaulting to True, of course).

Jonathan, Niall and I have been using the http://groups.google.com/group/js4py, which is really a group "for python programmers who are learning or using Javascript". I sent an email to the group, letting Jonathan and Niall know about the proposed merge of projects and asking if it's ok if we continue using the group for py2js emails (since we'll be generating heavy traffic over the next couple of weeks). Both Jonathan and Niall have been supportive of my recent work and have contributed a lot to architecture discussions and have also contributed some documentation and code.

> e.g. all unittests fail for me, so I must be executing them in some wrong way
I've significantly moving things around with the introduction of a solid javascript library dependency and have probably broken the old unit tests. Instead I've been creating and using documentation tests that I've written (a little different from doctests: they examine the bitbucket-wiki file and run the "Python:" examples and verify that the output matches the "Javascript:" side). I'll move this from a bitbucket wiki to a ReST file after the move to github. Two of these pass and one of them fails because I haven't yet rewritten the for-loops to generate less-verbose Javascript (I'll be working on this next). You can run these tests by running "python overview_tests.py".

I'm trying to write documentation examples/tests to show the style of non-verbose Javascript I want py2js to emit, in order to cast a solid vision of where I want the library to go, so with each test, I've had to go in and change py2js to make the output match... hence there aren't a lot of these tests yet (there are already more javascript tests and I only got that testing system up and running yesterday morning). BTW, overview_tests.py both runs the tests in the wiki Home.src file and also generates the destination wiki/Home.wiki file (adding some wiki-specific synax to the examples). I would like to split off the wiki-generation into a separate file (or just do away with it altogether, since we're moving to github, and convert the .src to ReST format) and move the core parsing code to utils.py so it can be shared.

To be honest, I assumed that the existing tests (like my doctests) were testing that the generated Javascript looked a certain way -- I just looked at them closely and realized they test that the OUTPUT from the JS and PY versions are identical. This is genius (wish I'd thought of it!) and I'm ashamed for having not looked closer at the unit tests. They'll need to be changd to include pylib.js in order for anything to pass.

My example-testing system allows the documentation to have anything (on the same line) after the initial "Javascript:" prefix. I'd like to support testing different flags using parentheses and a syntax like this:

Javascript: (language='js-1.8', js_lib_dependent=True)
emitted_js_code_here...


For the Javascript testing, I'm sticking with the doctest convention (I forked Ian Bicking's doctestjs and have made some heavy modifications, including a dependency on Python -- I'll extricate this from the project I've been developing it for, get it all moved over for use in py2js and also post it on bitbucket as doctestjs2). You can run the Javascript tests by running "python runtests.py", which should parse the javascript comments, built a JSON file from the results and then point your default browser at tests/pylib_tests.html.

> if the code cannot be compiled it should raise an exception
> like "Decorators are not supported"
Absolutely, I wholeheartedly agree. I think this error is due to a couple of decorator-specific lines I commented out to get py2js running on Python 2.6. Niall posted a more robust solution here http://groups.google.com/group/js4py/msg/e66275e857ea918a which should (I think) support both Python 2.6 and Python 2.5.

> I especially like if you can do doctest the js code itself
> and generate sphinx documentation, that is very important
Yes, I have code in another project I'll bring over that generates ReST documentation from the code. The comment-parsing is a little rudimentary and (at this point) disallows the use of multi-line comments in Javascript /* */ unless you want the stuff between the comments to show up in the docs. I tried implementing docstrings instead (__doc__ = "...") with the "\" line-continuation character, but you need to add explicit line-endings, so every line ends with "\n\", which is ugly beyond belief, especially when mixed in with doctests.

Also, it doesn't automatically generate the method definition ReST from the Javascript, for instance, you have to write that yourself, but it's worth it because then you can add in things like defaults and optional parameters. Here's an example of a sphinx/ReST-ready docstring using my parser:

function update(path, path_params, ent_id, check_table, force_table_refresh, files_on_disk) {
/*
.. method:: g_json_cache.update(path, path_params, ent_id, check_table, force_table_refresh, files_on_disk)

Updates the cache for the folder *path* and all its subfolders. If
*path_params* are not provided, they will be auto-generated based on the
*path* and *ent_id*. *path* is preferably absolute, but could be relative to
the `\App\` folder.

*path_params* is an object containing key/value pairs for any parameters in
the supplied (partial) path. This is necessary because the PathMapper doesn't
yet parse partial paths.

>>> var results = g_results.getAll({ filters: { id: 'TEST2009' }});
... results.team.del();
... path = g_base_path + '\\DataFiles\\Id\\TEST2009\\';
... g_json_cache.update(path, { id: 'TEST2009' }, 'RESULT');
Deleted 1 file: \DataFiles\Id\TEST2009\RESULT.json
*/
...
}


So you can see how the function definition is repeated, which is annoying, but OTOH this gives us the ability to add optional square brackets and defaults. It may be a simple approach, but I've found it very useful.

> We need good tests, which you seem to have
To be honest, I haven't looked at or run the unit tests yet. I

> Or we can have both py2js.py in there for people to choose the one they like better
No, I'd like to use yours as a base to start with and migrate any features we have that you don't onto your base.

> if we work together on this, we'll make it a nice and polished tool
Agreed. You may have noticed that I have lots of plans and lots of incomplete things. The main reason is that I have limited time -- I'm devoting some work time and a lot of evening/weekend time to this, but there are a number of work responsibilities for client-oriented projects that I need to be responsible and work on. For this reason, I've tried to focus my time on setting a solid vision for the project and on tackling the tricky/critical unknowns (like a function wrapper that handles args/kwargs appropriately and (next) a clean for loop mechanism).

-- peter

-----Original Message-----
From: ondrej...@gmail.com [mailto:ondrej...@gmail.com] On Behalf Of Ondrej Certik
Sent: Thursday, April 29, 2010 9:59 AM
To: Peter Rust
Subject: Re: Notification: py2js

Another thing --- should we use hg or git? I am familiar with both, I
used to use hg for all my stuff for about a year and then I got fedup
and switched to git, in case you are curious why, I wrote about it
here:

http://ondrejcertik.blogspot.com/2008/08/i-am-switching-from-mercurial-to-git.html
http://ondrejcertik.blogspot.com/2008/12/experience-with-git-after-4-months.html

and I use git for almost 2 years now every day and I am very happy
with it, it just made me so much more productive, especially when
working with other people.

But if you want to use hg, we have 3 options.

1) Either use hg as the main repository and then use fast-export:

http://repo.or.cz/w/fast-export.git

which can convert a mercurial repo to git, so that I can use it from
git, but it's not so easy to convert my git patches back to mercurial.

2) use git as the main repo and use fast-export to convert git to
mercurial, but again, it's then not easy to use your hg patches to
convert them back to git

3) use git as the main repo and use hg-git:

http://hg-git.github.com/

and then, as I understand it, you can just use hg to push your py2js
into a git repository (at github for example) and I can push and pull
from there from git, and you can also pull from there using hg. In
other words, we can even have one hg at bitbucket and the same repo at
github and we would use hg-git to make them synchronized.

So I would recommend 3). I am playing with it now, as I have never
used it much, and I'll let you know how it goes.

Ondrej

--
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.

[Peter Rust]

For posterity, here is the email I sent Ondrej late last night (so he can reply here, on-list, for all to see).

-- peter

-----Original Message-----
From: Peter Rust [mailto:pe...@cornerstonenw.com]

Sent: Wednesday, April 28, 2010 10:55 PM
To: 'ond...@certik.cz'
Subject: RE: Notification: py2js

Hello Ondrej Certik!

Great to hear from you! Yes, I think it would be beneficial for both of us to work together and merge our efforts.

I just looked over your code -- we have almost identical approaches. Our pylib.js corresponds to your builtins.js. Our jsmap.py corresponds to your name_map, bool_op, unary_op, binary_op and comparison_op dictionaries. Where your translation code is done in one file, fairly directly -- py2js.py -- ours is done in a less direct approach. First, in pyfrontend.py, the AST tree that python provides is transformed into a simpler tree (the various node types of the simpler tree are defined in parsetree.py). Then, in jsbackend.py, the tree is walked and Javascript is emitted.

Let me give you a brief background of our py2js project. It was started in October of 2008 by Niall McCarroll and he posted it here http://www.mccarroll.net/py2js/index.html. It was under development for a few months, but then development trailed off. Jonathan Fine found out about it and brought it into js4py (http://code.google.com/p/js4py/) -- a collection of various resources for pythonistas who were learning/using javascript.

I scoured the web, looking for similar projects -- and actually started one of my own using the ast module before I found this one and started working on it three days ago. Jonathan and Niall were very gracious, allowing me to start spearheading development, since the project hadn't seen much activity for a year. Jonathan even ran a jslint over my code and checked in some corrections.

Our code is in a significant state of upheaval. Niall had it tracking dependencies and only emitting the pieces of Javascript that were necessary -- I brought in the idea of having it depend on a stand-alone pylib.js (like your builtins.js), which has greatly simplified things. Also, we arrived at the same conclusion of creating list(), dict() and tuple() wrapper classes so I've been pushing on the javascript side, but the python side isn't yet generated the wrappers around literals.

There are still some spots where our python emits fairly verbose code -- for loops, for example -- but I hope to create some more concise looping functions in the pylib.js in order to make the emitted code cleaner.

I like what you've done with __len__ and __str__ and how you've implemented the various Error classes in Javascript -- I haven't gotten around to doing that. I'm not sure how much work it will be to merge the two projects, but for starters, merging the javascript libraries ought to be fairly straightforward, since they are so similar.

Both our dict wrappers wrap a javascript Object (we call it this._obj, you call it this._items), both our list wrappers wrap a javascript Array (we call it this._arr, you call it this._items). We haven't gotten around to implementing a Tuple class, it's nice to see that you have -- also nice to see the implementation sharing between the list and tuple prototypes. Perhaps at some point we could abstract it up to a base Sequence class or something.

We're putting everything behind closures and hanging everything off the $import object, to keep from cluttering the global javascript namespace -- a "keeping the music down for the neighbors" sort-of idea that Jonathan cares a lot about (and I like it too).

Something I just implemented this morning is args and kwargs unpacking -- both on the function calling side (sending in to a function $args(['item1', 'item2']) as JS equivalent of *['item1', 'item2'] -- and $kwargs() is the equivalent of **), and on the function definition side, if you declare an "args" argument, it will get a list of any extra arguments passed in -- if you declare a "kwargs" argument, it will get a dict of any extra arguments passed in (actually it's Array and Object right now, I need to wrap them in our list/dict classes).

I just started getting some basic doctests running in Javascript, you should be able to see them by running "python runtests.py", which should write a JSON file and fire up your default browser, pointing to the tests. In another project I have a bit more robust support for javascript doctests (multi-line tests, etc), so I'm hoping to bring that over. Also, I have it writing out ReST from the docstrings for sphinx-generated documentation, as you have. Here's what the Javascript doctests look like for the function wrapper I wrote this morning:

function def(func)

Wraps the supplied function in Pythonic goodness. The wrapper handles
unpacking **kwargs, unpacking *args, sending any extra arguments to the args
and kwargs parameters, sending `this` to the `self` parameter and setting the
`__name__` property.

Use the $args() wrapper instead of * to send in positional args for unpacking.
If the combination of regular arguments passed and $args() passed are more
than the number of declared arguments, the extra ones will be passed as a
list to the "args" parameter. If there is no "args" parameter defined on the
function, an error will be thrown.

>>> var fn1 = def(function(arg1, arg2) { return [arg1, arg2].join(', '); });
>>> fn1('test1', 'test2');
"test1, test2"
>>> fn1($args(['test1', 'test2']));
"test1, test2"
>>> fn1('test1', $args(['test2']));
"test1, test2"
>>> fn1('test1', $args(['test2', 'test3']));
Error: __name__() takes at most 2 arguments (3 given).

Use the $kwargs() wrapper instead of ** to pass in keyword arguments for
unpacking. If any kwargs are passed in that don't map to a declared
parameters, the extra ones will be passed in a dict to the "kwargs"
parameter. If the function doesn't declare a "kwargs" parameter, an error
will be thrown.

>>> fn1($kwargs({'arg2': 'test2', 'arg1': 'test1'}));
"test1, test2"
>>> fn1('test1', $kwargs({'arg2': 'test2'}));
"test1, test2"
>>> fn1($kwargs({'arg3': 'test3'}));
Error: __name__() got an unexpected keyword argument 'arg3'

Here is an example of declaring "args" and "kwargs" parameters to catch
extra arguments:

>>> var fn2 = def(function(arg1, args, kwargs) { return arg1 + ', ' + JSON.stringify(args) + ', ' + JSON.stringify(kwargs); });
>>> fn2($args(['test1']));
"test1, [], {}"
>>> fn2($args(['test1', 'test2']));
"test1, [\"test2\"], {}"
>>> fn2($kwargs({'arg1': 'test1', 'arg2': 'test2'}));
"test1, [], {\"arg2\":\"test2\"}"

I realized tonight at the Bellingham python user group that I missed an error case. In Python, if you define a function "def foo(arg1, arg2)" and pass in "foo('test1', arg1='something else')" it will throw a TypeError about multiple values for the same argument. In my Javascript implementation, the keyword-argument will override the positional one... I need to fix that.

Regarding the python side of things, I'm not sure there are any compelling advantages to our layered approach. I'll have to examine more closely what Niall is doing differently with the parsetree.py set of objects that couldn't be done more directly in visitor methods, as you're doing them. There is certainly an advantage to simplicity and not having too many layers, so if there's no compelling reason to keep it as is, I'll look at flattening our system so it looks more like yours and is easier to merge.

If you haven't noticed from my manifesto-style wiki page, I care a lot about generating clean-looking code that isn't too verbose. I like what you've done with for-loop implementation (using the .next() call and handling the StopIteration exception) and I'd like to do something like that, but I'd like to find a way to hide it a bit, so it doesn't bloat the generated code so much.

I've thrown around a couple approaches with a local pythonista, either something like this:

"for (var iter = iter(items); !(item instanceof StopIteration); item = trynext(iter))"

The "trynext" function would include the try/catch and return StopIteration as a return value -- this would allow us to not have a try/catch block in every emitted for loop, but also wouldn't properly handle the (extremely rare) case where the list we're iterating over actually has a StopIteration object in it.

Another option is to go the traditional iterms.forEach(function(item1, item2) { ... }) approach, which is a fairly clean syntax and I think FF3's native implementation may even support iterating over an object that throws a StopIteration exception -- yes, there's a native StopIteration exception in Javascript 1.7: https://developer.mozilla.org/en/New_in_JavaScript_1.7.

Anyways, all that to say that that's what I'm currently thinking about and working on.

What example were you running that generated the 'Name' AttributeError? I'd like to run it myself and debug it.

Before I came to the project, the code it was generating wasn't exactly clean and beautiful -- it was just getting the job done. I've cleaned up a few areas (almost all the examples on the wiki page are passing now), but there are still lots of areas (list comprehensions, *args and **kwargs, etc) that I still need to clean up.

Looking forward to working with you,

-- Peter Rust
Developer, Cornerstone Systems


-----Original Message-----
From: notificati...@bitbucket.org [mailto:notificati...@bitbucket.org]
Sent: Wednesday, April 28, 2010 7:09 PM
To: pe...@cornerstonenw.com
Subject: Notification: py2js

You have received a notification from certik.

Hi Peter,

we are developing this library:

http://mattpap.github.com/py2js/html/

using MIT license too, so I thought if we could work together on a common project. We accidentally call it py2js too and have the exact same goals. Do you have some better communication medium than this? My email is:

ond...@certik.cz

Accidentally, I was in Bellingham last week, but I didn't know about you...

I tried to run your py2js on our examples and it fails with:


File "/home/ondrej/repos/py2js-hg/pyfrontend.py", line 276, in Assign
expr = self.visit(ast.value)
File "/home/ondrej/repos/py2js-hg/pyfrontend.py", line 90, in visit
return getattr(self,name)(ast)
File "/home/ondrej/repos/py2js-hg/pyfrontend.py", line 225, in ListComp
generators.append(self.visit(g))
File "/home/ondrej/repos/py2js-hg/pyfrontend.py", line 90, in visit
return getattr(self,name)(ast)
File "/home/ondrej/repos/py2js-hg/pyfrontend.py", line 172, in comprehension
target = self.visit(e.left)
AttributeError: 'Name' object has no attribute 'left'


so I can't compare it yet. But in any case, I would like to join our forces.

Ondrej

http://ondrej.certik.cz

I am in this group: http://hpfem.org/

You may read it and others on http://bitbucket.org/notifications/

--
This is a notification from bitbucket.org.
You are receiving this because you have email notifications enabled.

[Ondrej Certik]

Hi,

to this, I have replied:

Hi Peter!

thanks for your long email! I completely agree with everything that
you wrote, we have the exact same goals.

My own goals are:

1) nice and readable javascript, which depends on a well designed and
polished (and documented!) pylib.js/builtins.js library
2) it must be easy to call any JS library
3) it must be easy to integrate the generated code with an existing JS
project (e.g. start by writing/rewriting couple functions into py2js
and then possibly porting more and more code to py2js)
4) it must be easy to debug it using standard JS tools
5) it should be usable now (i.e. get 90% there), which our py2js
already is, as we are starting to use it in our projects (some web
browser mesh editor and other gui stuff), I think your project is too,
and we'll just keep improving it on the way
6) the python -> JS translation should be as simple (and short) as
possible, so that it's easy to debug it, and implement new features,
possibly use a different pylib/builtins.js library, or even generate
code that doesn't depend on any JS support library at all (e.g.
list/tuples become Arrays and so on, obviously some features like
slicing would not be supported), so that it can be used to write low
level JS code, possibly even generating the pylib/builtins JS library
itself (not sure now if this goal is worthy or not).

So for example pyjamas fails 1), 3), 4) and 6).

We need to get a bit organized first --- do you mind setting up a
mailinglist at google groups? If so, I'll do it and invite you there.

I will then post there your email (or you can do it yourself) and then
I'll reply there. So that other people can easily join the
conversation and read the archives.

Plus I'll be posting there couple basic questions about your project,

e.g. all unittests fail for me, so I must be executing them in some

wrong way. Also about that AttributeError --- I strongly believe that

if the code cannot be compiled it should raise an exception like

"Decorators are not supported", so that the user knows what's wrong.
I'll post it to the list.

Our project started about a week ago, when me and Mateusz Paprocki
(another SymPy developer) who is visiting us here in Reno NV got fedup
with pyjamas and pyvascript (http://pyvascript.appspot.com/GoL) and
simply started our own thing. He designed the javascript library and
things were clear to both of us, that this is the way to go, which you
discovered as well. Your js library seems more advanced, so we should
probably take yours as the base. I especially like if you can do

doctest the js code itself and generate sphinx documentation, that is

very important (as I think we need to make the pylib.js a nice
standalone, well documented javascript library).

As to the translation itself, there I think it makes a lot of sense to
me to keep it as simple (and short) as possible, so that it's easy for
people to modify it. Maybe we can take our py2js.py and implement
there the missing features.

Which brings us to tests. We need good tests, which you seem to have,
then I can take my py2js.py and make sure that it passes all your
tests, and then I guess we can use it. Or we can have both py2js.py in
there for people to choose the one they like better.

In any case, I am very excited, because if we work together on this,
we'll make it a nice and polished tool.

Ondrej

[Ondrej Certik]

Hi,

On Thu, Apr 29, 2010 at 2:40 PM, Peter Rust <pe...@cornerstonenw.com> wrote:
> Ondrej,
>
> If it's trivial, I would like to try http://hg-git.github.com/ -- a co-worker here has been using it and it's been working well for him. There are a number of pythonistas using hg (my naïve impression is that the python community is currently split between hg and git with neither side having over 80%), so if it's trivial, it would be great to support both. If it becomes a problem or starts getting in our way, we can just go fully to git.
>
> Thanks for your other email, good stuff. How about we rename the javascript library to "py-builtins.js" and subtitle it "Python Builtins for Javascript" and refer to it in code with an underscore as "py_builtins"?

Yes, let's call it py-builtins.js.

>
> I'm tempted to have the javascript library in a separate repository, as it can be used standalone and will have separate documentation and separate tests. The problem with this is when certain versions of py2js emit code for certain versions of py-builtins.js. I have mixed feelings. I think 90% of the API between the two can be completed within the next week or two (but things always take twice as along as I estimate :). Once the API settles down, I think it would make sense to have them in separate repositories -- and right now, since both are under such active development (alpha stage), I don't know that we need to expend a lot of energy right now keeping them in sync and recording which versions of py2js depend on which versions of py-builtins.js...  what do you think?

I would keep everything in one repository for now. Later on, we might
refactor this if needed. I think that people would like to use
py-builtins.js in conjunction with py2js anyway though.

>
> Your idea (6b) of an option to generate code that doesn't depend on the JS lib at all is a good one. Something similar had crossed my mind, in fact, this is exactly what one of the guys in our local python group (http://github.com/fitzgen) wants from the project. He wants to write in Python syntax, but with Javascript built-ins, like "arr.push()" instead of "lst.append()". So it would be strictly a syntax converter. I don't want to expend a lot of energy on this, but it's actually more trivial than what we're doing now and shouldn't be too hard to implement/maintain alongside the lib-dependent code.

There are more decisions like this, as I wrote in my other email to this list.

>
> This actually goes along with the idea of a ff3 switch, but they would be different switches because they could be combined -- i.e. there are four possible combinations with the two switches.
>
> I'm thinking the one switch could be called "language" and could be set to "js-1.8" but would default to "ecma-3" (later someone may want to add support for js-1.6, js-1.7, ecma-6 or ecma-5). The other switch could be called "js_lib_dependent" and could just be True or False (defaulting to True, of course).
>
> Jonathan, Niall and I have been using the http://groups.google.com/group/js4py, which is really a group "for python programmers who are learning or using Javascript". I sent an email to the group, letting Jonathan and Niall know about the proposed merge of projects and asking if it's ok if we continue using the group for py2js emails (since we'll be generating heavy traffic over the next couple of weeks). Both Jonathan and Niall have been supportive of my recent work and have contributed a lot to architecture discussions and have also contributed some documentation and code.
>
>> e.g. all unittests fail for me, so I must be executing them in some wrong way
> I've significantly moving things around with the introduction of a solid javascript library dependency and have probably broken the old unit tests. Instead I've been creating and using documentation tests that I've written (a little different from doctests: they examine the bitbucket-wiki file and run the "Python:" examples and verify that the output matches the "Javascript:" side). I'll move this from a bitbucket wiki to a ReST file after the move to github. Two of these pass and one of them fails because I haven't yet rewritten the for-loops to generate less-verbose Javascript (I'll be working on this next). You can run these tests by running "python overview_tests.py".
>
> I'm trying to write documentation examples/tests to show the style of non-verbose Javascript I want py2js to emit, in order to cast a solid vision of where I want the library to go, so with each test, I've had to go in and change py2js to make the output match... hence there aren't a lot of these tests yet (there are already more javascript tests and I only got that testing system up and running yesterday morning). BTW, overview_tests.py both runs the tests in the wiki Home.src file and also generates the destination wiki/Home.wiki file (adding some wiki-specific synax to the examples). I would like to split off the wiki-generation into a separate file (or just do away with it altogether, since we're moving to github, and convert the .src to ReST format) and move the core parsing code to utils.py so it can be shared.
>
> To be honest, I assumed that the existing tests (like my doctests) were testing that the generated Javascript looked a certain way -- I just looked at them closely and realized they test that the OUTPUT from the JS and PY versions are identical. This is genius (wish I'd thought of it!) and I'm ashamed for having not looked closer at the unit tests. They'll need to be changd to include pylib.js in order for anything to pass.

I would really just test the output. That's all that matters. However,
I want to have a readable code, that's clear, but imho, that is just
the way it is actually implemented in py2js.py. I don't like testing
this too much, as then when you change how things are implemented
internally, you need to change the tests as well.

I like this. We should have the js library documented using sphinx and
your approach above.

>
>> We need good tests, which you seem to have
> To be honest, I haven't looked at or run the unit tests yet. I
>
>> Or we can have both py2js.py in there for people to choose the one they like better
> No, I'd like to use yours as a base to start with and migrate any features we have that you don't onto your base.
>
>> if we work together on this, we'll make it a nice and polished tool
> Agreed. You may have noticed that I have lots of plans and lots of incomplete things. The main reason is that I have limited time -- I'm devoting some work time and a lot of evening/weekend time to this, but there are a number of work responsibilities for client-oriented projects that I need to be

The same here. I am busy with other things, but we want to use this
for our GUI stuff in the browser, so that other people in our group
can just write Python (that everybody knows) and don't need to learn
javascript. In particular, we for example have a pure python
triangulation code, that our py2js can translate without any changes
(well, one little change from "while some_list != []:" into "while
len(some_list) > 0:") and it just works, see here for the code:

http://github.com/mattpap/py2js/blob/master/examples/triangulation.py

so we don't need to rewrite it to javascript at all.

> responsible and work on. For this reason, I've tried to focus my time on setting a solid vision for the project and on tackling the tricky/critical unknowns > (like a function wrapper that handles args/kwargs appropriately and (next) a clean for loop mechanism).

I agree that these tricky things can be done later. Important is to
get it working for our projects now and then just keep improving it.

[Jonathan Fine]

Thank you, Ondrej, for sharing your experience on git and hg.  I had a look at your blog pages.

On the basis of my experience, which covers different ground, I'm not persuaded.

What is clear to me is that git is better than hg for some things, and vice versa.


Jonathan

[Jonathan Fine]

On Thu, Apr 29, 2010 at 10:40 PM, Peter Rust <pe...@cornerstonenw.com> wrote:

 

Thanks for your other email, good stuff. How about we rename the javascript library to "py-builtins.js" and subtitle it "Python Builtins for Javascript" and refer to it in code with an underscore as "py_builtins"?

I'm tempted to have the javascript library in a separate repository, as it can be used standalone and will have separate documentation and separate tests. The problem with this is when certain versions of py2js emit code for certain versions of py-builtins.js. I have mixed feelings. I think 90% of the API between the two can be completed within the next week or two (but things always take twice as along as I estimate :). Once the API settles down, I think it would make sense to have them in separate repositories -- and right now, since both are under such active development (alpha stage), I don't know that we need to expend a lot of energy right now keeping them in sync and recording which versions of py2js depend on which versions of py-builtins.js...  what do you think?

Your idea (6b) of an option to generate code that doesn't depend on the JS lib at all is a good one. Something similar had crossed my mind, in fact, this is exactly what one of the guys in our local python group (http://github.com/fitzgen) wants from the project. He wants to write in Python syntax, but with Javascript built-ins, like "arr.push()" instead of "lst.append()". So it would be strictly a syntax converter. I don't want to expend a lot of energy on this, but it's actually more trivial than what we're doing now and shouldn't be too hard to implement/maintain alongside the lib-dependent code.

I think that the core JavaScript library is crucial for this project.  Many users, I think, would like to know 'what they get' from the code they write in Python, and calls to the core library are a very important part of that.

It is also something that wary JavaScript programmers will look at quite closely before using js2py, and so it had better be coded good.

I agree with Peter and Ondrej, that a shared core library is a good place to start merging the two py2js project.

--
Jonathan