Summary of phone meeting
Christian Iversen
Update: Sorry, I got delayed with the summary. I had to take care of an
urgent meeting.
As promised, I'm making a list of the topics discussed during the phone
meetings yesterday. I think we should have more of those, since it is so
much easier to communicate. Then, when we agree on a model, we can
archive it on the mailing list. That means we can spend more time
programming, and less time typing :)
I'll try to include all the topics in this email, but since we covered a
lot of ground (Sam, I talked to Certik after our conversation), I might
have left something out by mistake. If so, please feel free to add it.
Also, let me know if you disagree about anything.
### 1: Fundamental design ideas ###
We have all looked at pyjamas, and have all concluded that it suffers
from the following design flaws:
a) Everything is javascript. No html is generated.
b) It tries to do everything (and they still conclude
that it's not possible)
c) It has a very large standard library, and even emulate some C-code
(the BigInt implementation, for example).
So, what we all want, is a light-weight project that enables:
a) Compilation of python into javascript..
b) ..with the support of a reasonable standard library
c) Support for module loading, so people can compile or create
their own libraries.
d) Interfacing javascript in python AS WELL AS python in javascript.
Point d) is very important. We will get back to that.
### 2: Classes need improvements to work ###
I've created some code that can be the basis for a new implementation of
classes. It has the following advantages:
a) Classes are real objects now
b) __foo__ works in classes, because they can be shared with
the instance
c) When converting the python "FooClass(...)" construction syntax
into js, we get FooClass.__call__(...). This method is then simply
implemented in js. We no longer require FooClass to be a function
(even though it might still be)
d) We no longer have to use hacks to make __getattr__ and __setattr__
work on classes. This fixes the unit tests, as well as real-life
programs using those functions.
### 3: Method of compilation ###
Currently, py2js performs compilation as a mix of syntactical and
semantical compilation. Let me underline that this is _totally_ bogus,
and does not actually work for a broad range of cases.
Le me show you the difference. Considering the python code
x["foo"] = y.bar(baz.flip)
Syntactically, this becomes:
x["foo"] = y.bar(baz.flip)
in javascript. However, semantically, this becomes:
x.__setitem__("foo",
y.__getattr__("bar").__call__(
baz.__getattr__("flip")
)
)
When interfacing with javascript native types, we need syntactical
compilation, and for interfacing with python-javascript types, we need
semantic compilation.
The current situation is terrible. For some cases, syntax compilation is
used, and for some, semantic.
What I think we can agree about after the talks, is that we need some
way to differentiate between pythonic and javascripty space.
For me, after having talked to Sam first, and then Certik, the
revelation came when I realized that only the identifier name is
required for discerning the mode. So, the compiler must be able to
switch between the two modes of compilation, depending on which
idenfifiers are being used. This would also totally eliminate the need
for the js() function being used explicitly, as the compiler could
auto-deduct this.
For me, this is by far the most important point we have discussed.
This is just an idea, but consider this example:
from __js__ import "jQuery"
jQuery("#a1").click(
lambda: jQuery("#button").button("option", "disabled",
myobject.button_disabled(data))
)
Now, without the compiler knowing about jQuery being javascripty, it
would generate something like the following code: (after our __foo__
changes):
jQuery.__call__(str("#a1").__getattr__(str("click")).__call__(
function() {
jQuery(str("#button")).__getattr__(str("button")).__call__(str("option",
str("disabled"), myobject.__getattr__("button_disabled").__call__(data));
};
);
With the compiler knowing about it, it will treat it as a javascript member:
jQuery("#a1").click(
function () {
jQuery("#button").button("option", "disabled",
js(myobject.__getattr__("button_disabled").__call__(data)))
};
);
So with this method, we can solve all of our interfacing problems!
### 4: Parameters ###
We really need to fix our parameter handling. I think Sam has a very
good suggestion for this: decorate the functions with varargs and
kwargs. Default values can be easily handled inside the function itself,
with some simple code.
This could be implemented like so:
fun.varargs = [1, 2, 3, 4, 5];
fun.kwargs = {"varname":value};
fun.defaults = fun.func_defaults.concat([]);
func.apply(this, arguments);
I think this style has lots of potential, and is a very good way to move
forward.
### 5: End ###
Sorry, this got to be quite a long mail also :)
However, I hope that we are now much closer to agreeing on our goals,
our ways to get there, and what we expect from the process.
I would like to talk to you both again soon, to further discuss these
plans. However, I need to know if you agree with this summary. If not,
we can discuss the details over the phone, but it would be great if you
could each write whether or not you agree with each point 1, 2, 3 and 4.
When we all have the same idea, we can talk about who will code what,
and that's the exciting part, after all :-)
Looking forward to talking to you again.
--
Med venlig hilsen / Best regards
Christian Iversen
Sikkerhed.org ApS
Fuglebakkevej 88 E-mail: sup...@sikkerhed.org
1. sal Web: www.sikkerhed.org
DK-2000 Frederiksberg Direkte: c...@sikkerhed.org
Ondrej Certik
+1
>
> ### 3: Method of compilation ###
>
> Currently, py2js performs compilation as a mix of syntactical and semantical
> compilation. Let me underline that this is _totally_ bogus, and does not
> actually work for a broad range of cases.
>
> Le me show you the difference. Considering the python code
>
> x["foo"] = y.bar(baz.flip)
>
> Syntactically, this becomes:
>
> x["foo"] = y.bar(baz.flip)
>
> in javascript. However, semantically, this becomes:
>
> x.__setitem__("foo",
> y.__getattr__("bar").__call__(
> baz.__getattr__("flip")
> )
> )
>
> When interfacing with javascript native types, we need syntactical
> compilation, and for interfacing with python-javascript types, we need
> semantic compilation.
>
> The current situation is terrible. For some cases, syntax compilation is
> used, and for some, semantic.
>
> What I think we can agree about after the talks, is that we need some way to
> differentiate between pythonic and javascripty space.
>
>
> For me, after having talked to Sam first, and then Certik, the revelation
Btw, my first name is Ondrej.
> came when I realized that only the identifier name is required for
> discerning the mode. So, the compiler must be able to switch between the two
> modes of compilation, depending on which idenfifiers are being used. This
> would also totally eliminate the need for the js() function being used
> explicitly, as the compiler could auto-deduct this.
>
> For me, this is by far the most important point we have discussed.
>
> This is just an idea, but consider this example:
>
> from __js__ import "jQuery"
This should actually be:
from __js__ import jQuery
>
> jQuery("#a1").click(
> lambda: jQuery("#button").button("option", "disabled",
> myobject.button_disabled(data))
> )
>
> Now, without the compiler knowing about jQuery being javascripty, it would
> generate something like the following code: (after our __foo__ changes):
>
> jQuery.__call__(str("#a1").__getattr__(str("click")).__call__(
> function() {
> jQuery(str("#button")).__getattr__(str("button")).__call__(str("option",
> str("disabled"), myobject.__getattr__("button_disabled").__call__(data));
> };
> );
>
> With the compiler knowing about it, it will treat it as a javascript member:
>
> jQuery("#a1").click(
> function () {
> jQuery("#button").button("option", "disabled",
> js(myobject.__getattr__("button_disabled").__call__(data)))
> };
> );
>
> So with this method, we can solve all of our interfacing problems!
+1
To keep focused, let's discuss this in the thread "2 modes of the
compiler". You are suggesting mode "c)". I like this mode the best
too. But let's discuss this part in that thread.
>
> ### 4: Parameters ###
>
> We really need to fix our parameter handling. I think Sam has a very good
> suggestion for this: decorate the functions with varargs and kwargs. Default
> values can be easily handled inside the function itself, with some simple
> code.
>
> This could be implemented like so:
>
> fun.varargs = [1, 2, 3, 4, 5];
> fun.kwargs = {"varname":value};
> fun.defaults = fun.func_defaults.concat([]);
> func.apply(this, arguments);
>
> I think this style has lots of potential, and is a very good way to move
> forward.
+1
>
> ### 5: End ###
>
> Sorry, this got to be quite a long mail also :)
>
> However, I hope that we are now much closer to agreeing on our goals, our
> ways to get there, and what we expect from the process.
>
> I would like to talk to you both again soon, to further discuss these plans.
> However, I need to know if you agree with this summary. If not, we can
> discuss the details over the phone, but it would be great if you could each
> write whether or not you agree with each point 1, 2, 3 and 4. When we all
> have the same idea, we can talk about who will code what, and that's the
> exciting part, after all :-)
+1
Ondrej
Ondrej Certik
From my perspective, the highest priority is:
1) Implement the "2 methods of compilation"
2) Modules
Because then lots of people can readily start using py2js for real
life problems and contributing code back for all kinds of modules.
Polishing kwargs, classes and other things (like py-builtins.js) can
be done as we go, at least for me, it is not a show stopper.
But I understand, and totally respect if you have a different order of
priorities. I just wanted to let you know where I stand.
Ondrej
Neppord
Nice wall of text ^^. I think you really got the point of most of it.
I leave som coments below.
3 mar 2011 kl. 23:59 skrev Christian Iversen <c...@sikkerhed.org>:
> Hey guys
>
> Update: Sorry, I got delayed with the summary. I had to take care of an urgent meeting.
>
> As promised, I'm making a list of the topics discussed during the phone meetings yesterday. I think we should have more of those, since it is so much easier to communicate. Then, when we agree on a model, we can archive it on the mailing list. That means we can spend more time programming, and less time typing :)
>
> I'll try to include all the topics in this email, but since we covered a lot of ground (Sam, I talked to Certik after our conversation), I might have left something out by mistake. If so, please feel free to add it. Also, let me know if you disagree about anything.
>
> ### 1: Fundamental design ideas ###
>
> We have all looked at pyjamas, and have all concluded that it suffers from the following design flaws:
>
> a) Everything is javascript. No html is generated.
Yes and no! It dose generate HTML, which is bad cause it makes it html dependent. But i understand you as you what a templating system?
> b) It tries to do everything (and they still conclude
> that it's not possible)
> c) It has a very large standard library, and even emulate some C-code
> (the BigInt implementation, for example).
Wow? I diddent know that?
d)they use Java naming conventions and library design patterns.
>
> So, what we all want, is a light-weight project that enables:
>
> a) Compilation of python into javascript..
> b) ..with the support of a reasonable standard library
> c) Support for module loading, so people can compile or create
> their own libraries.
> d) Interfacing javascript in python AS WELL AS python in javascript.
>
> Point d) is very important. We will get back to that.
Don't think you do get back to that.
Hurray! Think this is hard(but possible) to trac. Have coments on this though, nothing agresiv or any thing but I think we need a voice chat again.