Re: [pypy-dev] pypy with sympy
In a message of Sat, 15 Sep 2007 15:17:34 +0200, "Ondrej Certik" writes: <snip>
So what is your priority now with pypy? I think it has such an enormous potential, but currently for me it's just a playground. Do you plan to apply pypy in some area, where people will use it as the best technology available in there? Or do you plan more to have pypy just as a means of testing new JIT ideas?
Ondrej
We really want to push this as a real language that people should use to solve real problems they have. Currently, however, things are in a bad need of a cleanup. While it was terrific to have the EU funding which let many of us work on pypy full time, the deadlines for deliverables were such that many things were hacked together in ways that are ok for a prototype but not really robust enough for production use. We are planning our next sprint to work on the roughest of these. Then, of course, the problem is that there are so many things that could be the 'next step' for PyPy. Some of us (me for instance) are actively looking for paying customers who have a business case for wanting PyPy to do X. Tim Parkin, who designed the current python.org site is also interested in working on finding out what should be the next step for PyPy. He is collecting opinions, and people who are willing to put money where their mouth is here: http://wiki.python.org/moin/PyPyDonations It would be nice to get PyPy to such a state that it again had many tasks for those people who don't feel up to hacking the Just in Time Specialiser. A better garbage collector is necessary, but I think that people find that intimidating as well. We're much further along with the new scheme for working with C extensions, and that too is necessary. It would be nice to find out exactly who wants what next from PyPy, and perhaps more importantly, who would be willing to help on PyPy, but cannot now, and what they would need in the way of changes before they could contribute. Besides fixes for the bugs you have reported, is there anything in particular you wish we were doing next? Laura
Then, of course, the problem is that there are so many things that could be the 'next step' for PyPy. Some of us (me for instance) are actively looking for paying customers who have a business case for wanting PyPy to do X. Tim Parkin, who designed the current python.org site is also interested in working on finding out what should be the next step for PyPy. He is collecting opinions, and people who are willing to put money where their mouth is here: http://wiki.python.org/moin/PyPyDonations
I'd suggest to put that link on the front page of pypy. And also to put that question where to go now on the front page. Compared to your donations, I hope you won't take mine as an offence, but I am a student.
It would be nice to get PyPy to such a state that it again had many tasks for those people who don't feel up to hacking the Just in Time Specialiser. A better garbage collector is necessary, but I think that people find that intimidating as well. We're much further along with the new scheme for working with C extensions, and that too is necessary.
It would be nice to find out exactly who wants what next from PyPy, and perhaps more importantly, who would be willing to help on PyPy, but cannot now, and what they would need in the way of changes before they could contribute. Besides fixes for the bugs you have reported, is there anything in particular you wish we were doing next?
I have many ideas: 1) Make predictable releases, get pypy into distributions, fix bugs and just make it another Python interpreter. 2) Provide a standard interpreter to: java, .NET and other platforms. In Jython, they need to code it in Java, by hand I guess. In PyPy, if I understand it correctly, you just update the interpeter in rpython and you get all those interpreters and all platforms for free. I guess this is one of the goals of pypy. So that for example SymPy can be run on all those platforms. 3) Allow efficient writing of modules in C/Fortran. There is SWIG, ctypes, f2py, then there are many projects like pyrex, Cython, etc. It's a mess. I think pypy has also something to say in this area and maybe make things more systematic, robust and multiplatform. 4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain. 5) Google Web Toolkit, but in Python using PyPy. It's a lot of work, nevertheless it's already possible and that would be a boom to pypy and python in general, I am pretty sure about that. 6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something. 7) Using RPython as a compiled languge. Generally, many of my algorithms are just RPython. If they could be tranlated to C and all the other backends, the same efficient as I would do by hand, that'd be just awesome. This is connected to 4). 8) This is very long term thing - the whole pypy machinery should in principle allow to run Python on basically everything. So knowing Python could be enough to contribute to a project written in almost any language. Anyway, I think pypy either can already do the things above, or has a very big potential to do so, like a proof of concept. Ondrej
Hi Ondrej,
I have many ideas:
1) Make predictable releases, get pypy into distributions, fix bugs and just make it another Python interpreter.
That one is a bit boring, don't you think? :-) No seriously, we can't really compete with CPython on its home turf, we need additional features that set us apart.
2) Provide a standard interpreter to: java, .NET and other platforms. In Jython, they need to code it in Java, by hand I guess. In PyPy, if I understand it correctly, you just update the interpeter in rpython and you get all those interpreters and all platforms for free. I guess this is one of the goals of pypy. So that for example SymPy can be run on all those platforms.
Yes, that's correct. We are working on this, actually. Especially Java is interesting, I guess, since Jython is still behind CPython. Competing with IronPython won't be so easy.
3) Allow efficient writing of modules in C/Fortran. There is SWIG, ctypes, f2py, then there are many projects like pyrex, Cython, etc. It's a mess. I think pypy has also something to say in this area and maybe make things more systematic, robust and multiplatform.
4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain.
This, too, is definitely part of PyPy's agenda. We plan to work on this not even too far into the future, I would think.
5) Google Web Toolkit, but in Python using PyPy. It's a lot of work, nevertheless it's already possible and that would be a boom to pypy and python in general, I am pretty sure about that.
In my opinion this is way outside what the current team of people actively working on PyPy can manage. We would need outside people that are ready to work on this.
6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something.
Right now we have a GIL as well, since it was easiest to implement. It's too early to think about removing the GIL, since we would need a better thread-aware garbage collector first – Boehm is just not up to the task.
7) Using RPython as a compiled languge. Generally, many of my algorithms are just RPython. If they could be tranlated to C and all the other backends, the same efficient as I would do by hand, that'd be just awesome.
Not sure whether it is as efficient as by hand, but such a translation is obviously possible.
This is connected to 4).
I disagree with this. The JIT techniques that PyPy uses are very different from its RPython translators.
8) This is very long term thing - the whole pypy machinery should in principle allow to run Python on basically everything. So knowing Python could be enough to contribute to a project written in almost any language.
I guess so, yes. Although right now our Python interpreter is not exactly lightweight, so running on very small machines is not going to be reasonable without quite some additional work. Cheers, Carl Friedrich
Hey, Carl Friedrich Bolz wrote:
1) Make predictable releases, get pypy into distributions, fix bugs and just make it another Python interpreter.
That one is a bit boring, don't you think? :-) No seriously, we can't really compete with CPython on its home turf, we need additional features that set us apart.
Heh, it's definitely boring, but it's essential if you want PyPy to be adopted more widely. You already have plenty of features. I want PyPy to be in a state so I can use it in production. :) Regards, Martijn
Hi Martijn, 2007/9/19, Martijn Faassen <faassen@startifact.com>:
Carl Friedrich Bolz wrote:
1) Make predictable releases, get pypy into distributions, fix bugs and just make it another Python interpreter.
That one is a bit boring, don't you think? :-) No seriously, we can't really compete with CPython on its home turf, we need additional features that set us apart.
Heh, it's definitely boring, but it's essential if you want PyPy to be adopted more widely. You already have plenty of features. I want PyPy to be in a state so I can use it in production. :)
I was referring to the "make it another Python interpreter", not to the first part. Probably wasn't all too clear. Cheers, Carl Friedrich
I was referring to the "make it another Python interpreter", not to the first part. Probably wasn't all too clear.
Well, but I think that "make it another Python interpreter" is maybe boring but essential. When substituting pypy for python, it shoud just work. Ondrej
Laura Creighton wrote: [snip]
It would be nice to find out exactly who wants what next from PyPy, and perhaps more importantly, who would be willing to help on PyPy, but cannot now, and what they would need in the way of changes before they could contribute. Besides fixes for the bugs you have reported, is there anything in particular you wish we were doing next?
I'm glad to see this important discussion is taking place again. For my input, see my mails from a few months ago. :) Regards, Martijn
participants (4)
-
Carl Friedrich Bolz
-
Laura Creighton
-
Martijn Faassen
-
Ondrej Certik