On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > >On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > >>This is a joke, right? > >Because it's a good idea to have to write separate wrappers > >around every useful library for each dynamic languague separately? > > If a project has done this successfully, I don't think I've seen it. Can > you point out some examples where this has been accomplished in a useful > form? The nearest thing I can think of is SWIG, which is basically a > failure.
SWIG is not my favorite (msotly because I don't like C++ much) but it's used very effectively here at Google (for example); I wouldn't dream of calling it a failure. I also consider .NET's CLR a success, based on the testimony of Jim Hugunin (who must be Microsoft's most reluctant employee :). And I see the JVM as a successful case too -- Jython can link to anything written in Java or compiled to JVM bytecode, and so can other languages that use JVM introspection the same way as Jython (I hear there's Ruby analogue). The major difference between all these examples and ctypes is that ctypes has no way of introspecting the wrapped library; you have to repeat everything you know about the API in your calls to ctypes (and as was just shown in another thread about 64-bit issues, that's not always easy). > This is not to say that it is not a noble goal, but I think it remains to > be shown that Parrot is actually a solution here. Parrot definitely has to show itself still. But a year ago Sam Ruby reported on his efforts of making Python work on Parrot, and he sounded like it was very a feasible proposition. > Parrot has been around for quite a while now without accomplishing anything > much of practical value. Does anyone _use_ it for Ruby, JavaScript, or Tcl? > (I know no one uses it for Perl 6 ;) > > For five years of development by a pretty large community, that's not showing > a lot. The reason I suspected a joke is that you seem to want to discard a > fairly good existing widely used solution in favor of one that's just vapor > right now. Granted Py3k is a ways off, but it's not /that/ far off. We're > talking about a year or two here. Is Parrot going to be as solid in a year > as ctypes already is? I doubt it. That's not exactly the point I am making. I find Parrot's approach, assuming the project won't fail due to internal friction, much more long-term viable than ctypes. The big difference being (I hope) introspective generation of APIs rather than having to repeat the linkage information in each client language. > If you /really/ want to look outside of the Python community for solutions > here, the lisp community has thought about this for a long time. Instead of > looking at Parrot, you should look at the ffi provided by almost any lisp > runtime. This seems a mostly theoretical viewpoint to me. Can you point me to an example of a Python-like language that is successful in reusing a Lisp runtime? (And I don't consider Lisp or Scheme Python-like in this context. ;-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
