On Wed, Nov 20, 2013 at 4:01 PM, Amirouche Boubekki <
amirouche.boube...@gmail.com> wrote:

>
> 2013/11/20 Lex Berezhny <l...@damoti.com>
>
>> Hi Amirouche,
>>
>> Can you provide some more details on what you see being merged?
>>
>
> We could share demos, compatibility test suite, documentation, etc...
>


I'm not sure about demos and documentation (given our APIs/goals might be
different) but I can see there being a benefit to a shared compatibility
test suite.

I think it would be cool if there was a "test suite" project that you could
then pass in your python->js compiler function and it would run a whole
bunch of tests and return the results. There is definitely lots of merit
there.

I can't imagine it would be hard to convince other projects to also use and
contribute to a shared test suite given that testing Python compatibility
is going to be the same regardless of your particular translator
implementation.

For each test the suite would use the supplied translator function to
convert Python->JavaScript then execute it in a JS engine and check state
of output.

Someone just has to start such a project.


 If you are asking whether you can become a contributor on pyjs then I
>> would say of course!
>>
>
> The thing is in Pythonium we get the extra feature that the three flavors
> of the compiler (Core, Veloce & Compliant) will be somewhat compatible so
> that people can downgrade easly from one version to another. This is the
> extra feature I really like, since it allows to create in pure Python and
> then have the extra flexibility to optimise critical paths.
>


In Pyjs you can get dozens of flavors by passing different arguments to the
translator command. You can achieve Pythonium Core by using the
--enable-stupid-mode translator flag. Take a look at some of the available
translator flags:


  -h, --help            show this help message and exit
  -o OUTPUT, --output=OUTPUT
                        Place the output into <output>
  -m MODULE_NAME, --module-name=MODULE_NAME
                        Module name of output
  -i, --list-imports    List import dependencies (without compiling)
  -D, --enable-default  (group) enable DEFAULT options
  -d, --enable-debug    (group) enable DEBUG options
  -O, --enable-speed    (group) enable SPEED options, degrade STRICT
  -S, --enable-strict   (group) enable STRICT options, degrade SPEED
  --enable-wrap-calls   enable call site debugging [False]
  --enable-print-statements
                        enable printing to console [True]
  --enable-check-args   enable function argument validation [False]
  --enable-check-attrs  enable attribute validation [False]
  --enable-accessor-proto
                        enable __get/set/delattr__() accessor protocol
[True]
  --enable-bound-methods
                        enable proper method binding [True]
  --enable-descriptor-proto
                        enable __get/set/del__ descriptor protocol [False]
  --enable-track-sources
                        enable tracking original sources [False]
  --enable-track-lines  enable tracking original sources: every line [False]
  --enable-store-sources
                        enable storing original sources in javascript
[False]
  --enable-inline-code  enable bool/eq/len inlining [False]
  --enable-operator-funcs
                        enable operators-as-functions [True]
  --enable-number-classes
                        enable float/int/long as classes [False]
  --enable-locals       enable locals() [False]
  --enable-stupid-mode  enable minimalism by relying on javascript-isms
                        [False]
  --use-translator=TRANSLATOR
                        override translator [proto]


I reviewed some of the Pythonium Core code and I'm not sure if any of that
>> would be worth merging with pyjs. It seems like very preliminary
>> experimental implementation.
>>
>
> Actually it's the 4th complete rewrite I do. Pythonium Core flavor, the
> only code available yet, only aims at supporting JavaScript semantic with a
> Python syntax.
>


I don't mean to diminish your work in anyway but I'm just not sure I
understand the point of Pythonium Core given all of the existing solutions
out there. There are dozens of Python->JavaScript translators that ignore
semantics.



>  The difference between pyjs and literally every other Python to
>> JavaScript implementation out there is that pyjs actually supports 95% of
>> Python semantics... including multiple inheritance, etc.
>>
>> Personally, unless the eventual goal is 100% Python support I don't see
>> any point in these semantic-free translators.
>>
>
> It is aiming 100% support.
>


It took many years for Pyjs to get to where it is today. I hope you are
successful in your efforts. I think I speak for more than just myself when
I say it would be awesome to have a new clean implementation of the Python
semantics. Pyjs works but it is rather crufty and difficult to maintain.

Have you come up with a speedy solution for true multiple inheritance and
attribute lookups (part of the 5% missing from Pyjs)? I have a prototype
that I've thrown together that uses JavaScript prototypes to create an
inheritance chain, it even supports super classes modifying their own bases
and this propagates to sub-classes (including instances of subclasses) and
because it uses prototypes there isn't a huge performance penalty. If you
are interested I can send you the code.



>  If you just want an alternative to writing JS syntax I would highly
>> recommend CoffeeScript. And if you want to re-use code between CPython and
>> a web browser than you can't really avoid implementing as much of Python
>> semantics as possible. Pyjs gets enough of the semantics implemented to be
>> productive but once you start trying to build frameworks or more complex
>> code the remaining 5% of missing semantics really gets in the way. That's
>> where we need the most help and effort.
>>
>
> Thanks for pointing me in the right direction.
>

If you decide to continue with your separate project I can see two
different paths of collaboration for Pythonium and Pyjs:

1. test suite as discussed earlier
2. a runtime engine, you call this "pythonium.veloce.js" in your readme

I think both of those could be independent projects that both Pyjs and
Pythonium could depend on and thus allow some diversity and at the same
time some re-use of resources on the really hard stuff.

 - lex

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Pyjs.org Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyjs-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to