Neal Becker wrote:
David Cournapeau wrote:
Carl Friedrich Bolz wrote:
Neal Becker wrote:
[...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish
David Cournapeau wrote:
No. You can use py++ if you like to generate boost::python. This (py++) is
fairly new, and I believe relatively few boost::python users follow this
route. Most of us write boost::python wrappers by hand (it's usually
pretty easy).
I was talking in the context of
Amaury Forgeot d'Arc wrote:
wxPython has the same number of functions, and uses Swig to do the wrapping.
swig parses C++ headers, and basically a significant part of C++. There
is really no way to do any kind of wrapping of C++ without parsing it,
or at least a significant portion of it.
Charles Oliver Nutter wrote:
Wiring in support for calling Java libraries won't be particularly
difficult, given the many reflective capabilities already present for
Java. But I agree it needs to be there for most people to find a lot of
use.
Indeed, I think this is the easiest part to
Antonio Cuni wrote:
The JVM backend has been mostly written by me and Niko Matsakis. At the
moment both of us work on it in our spare time, but if my phd proposal
gets accepted I should be able to work on it much more continuously.
That's excellent. Having just completed a dynlang compiler
Neal Becker wrote:
[...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish pypy could do the same.
Both methods involve parsing C++, which is not fun.
[...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish pypy could do the same.
Both methods involve parsing C++, which is not fun. For example,
On Wed, 14 Nov 2007 17:16:48 +0100, Carl Friedrich Bolz [EMAIL PROTECTED]
wrote:
Hi all,
I thought I would start a new thread for discussing what PyPy needs to
become production ready (whatever that is) and succeed as a Python
implementation. This is something were outside opinions are very
David Cournapeau wrote:
Carl Friedrich Bolz wrote:
Neal Becker wrote:
[...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish pypy could do the
Carl Friedrich Bolz wrote:
Neal Becker wrote:
[...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish pypy could do the same.
Both methods involve
Hi,
Maciej Fijalkowski wrote:
But besides, I fully agree to the BIG FAT WARNING. This code is mostly
there for tests. Even strings should not cross this border
Hmm, it seems quite stable, though (besides a few bug in the exception
handling). Note that passing and receiving strings works fine
* Neal Becker [EMAIL PROTECTED] [2007-11-16 09:41:12 -0500]:
No. You can use py++ if you like to generate boost::python. This (py++) is
fairly new, and I believe relatively few boost::python users follow this
route. Most of us write boost::python wrappers by hand (it's usually
pretty
Antonio Cuni wrote:
If you meant a Python to JVM bytecode compiler, that's what I was
talking about too :-).
I'm not sure that having it will cover 90% of people interested in
pypy-jvm; to fully exploit python on jvm we need to allow access to Java
classes from Python (and vice-versa), but
David Cournapeau wrote:
Martijn Faassen wrote:
Yes, this one would be a major challenge. If you can crack it and the
PyPy interpreter offers another benefit (an obvious one is speed), you
will be in awesome position. If not, the other benefits will have to
weigh more strongly. This is
David Cournapeau wrote:
Martijn Faassen wrote:
Yes, this one would be a major challenge. If you can crack it and the
PyPy interpreter offers another benefit (an obvious one is speed), you
will be in awesome position. If not, the other benefits will have to
weigh more strongly. This is
David Cournapeau wrote:
Martijn Faassen wrote:
Yes, this one would be a major challenge. If you can crack it and the
PyPy interpreter offers another benefit (an obvious one is speed), you
will be in awesome position. If not, the other benefits will have to
weigh more strongly. This is
In a message of Wed, 14 Nov 2007 17:40:54 GMT, Douglas McNeil writes:
/lurk
Arbitrary code is less interesting to me than JIT-powered fast numerical
code. Moreover, we numerics types have much lower standards of
production ready than the general public, and are willing to turn on
options with
Amaury Forgeot d'Arc wrote:
David Cournapeau wrote:
Martijn Faassen wrote:
Yes, this one would be a major challenge. If you can crack it and the
PyPy interpreter offers another benefit (an obvious one is speed), you
will be in awesome position. If not, the other benefits will have to
weigh
Hi all,
I thought I would start a new thread for discussing what PyPy needs to
become production ready (whatever that is) and succeed as a Python
implementation. This is something were outside opinions are very welcome
(of course there is no guarantee we can implement all of your wishes :-)
).
Carl Friedrich Bolz wrote:
- for PyPy-JVM: bindings to allow the interaction with arbitrary Java
libraries, threading support
Moreover, I would add to this list that the possibility to compile
python to jvm bytecode instead of python bytecode; maybe a pypy-jvm
would be usable even
cfb wrote:
I thought I would start a new thread for discussing what PyPy needs to
become production ready (whatever that is) and succeed as a Python
implementation.
[...]
- Speed. The JIT is still not in a state where it really speeds up
arbitrary Python code. I expect this to change
Just a small note. We've got nowadays pieces of code that can help you
handle safety-for-speed even in compiled rpython code, --sandbox uses those.
(Like check for NULL pointers, enable assertions, etc.)
But besides, I fully agree to the BIG FAT WARNING. This code is mostly there
for tests. Even
Antonio Cuni wrote:
Carl Friedrich Bolz wrote:
- for PyPy-JVM: bindings to allow the interaction with arbitrary Java
libraries, threading support
Moreover, I would add to this list that the possibility to compile
python to jvm bytecode instead of python bytecode; maybe a pypy-jvm
Martijn Faassen wrote:
- for PyPy-JVM: bindings to allow the interaction with arbitrary Java
libraries, threading support
Does this already exist for PyPy-CLR?
yes, but it's more or less only a proof of concept. You can use .NET
classes from Python but you can't, e.g., inherit from a
Charles Oliver Nutter wrote:
Moreover, I would add to this list that the possibility to compile
python to jvm bytecode instead of python bytecode; maybe a pypy-jvm
would be usable even without it, but e.g. developing applets requires
it.
Hopefully, I'll be able to work on this (an its
From previous discussions, I suspect I'm not the only lurker-fan who would
be willing to commit time to working on numericentric graph optimizations
when that becomes a worthwhile investment. There's no reason that the
mostly-fortran bits of python code shouldn't run almost as fast as fortran
Hey Carl,
Carl Friedrich Bolz wrote:
I thought I would start a new thread for discussing what PyPy needs to
become production ready (whatever that is) and succeed as a Python
implementation. This is something were outside opinions are very welcome
(of course there is no guarantee we can
27 matches
Mail list logo
