[Python-Dev] Re: a serious threat to 2.3's speed?

Samuele Pedroni pedronis at bluewin.ch
Thu Dec 11 15:52:54 EST 2003

At 06:57 12.12.2003 +1100, Delaney, Timothy C (Timothy) wrote:
> > From: Duncan Booth
> >
> > The interface includes methods:
> >
> >    PyObject __call__();
> >    PyObject __call__(PyObject arg1);
> >    PyObject __call__(PyObject arg1, PyObject arg2);
> >    PyObject __call__(PyObject arg1, PyObject arg2, PyObject arg3);
> >    PyObject __call__(PyObject[] args);
> >    PyObject __call__(PyObject[] args, PyDict keywordArgs);
>Hmm - IIRC that's how Jython does it.

yup, but it doesn't try to profit from this organization as much as it 
could, and it queries some ad-hoc per-thread storage at each function call, 
instead of passing
the data along from caller to callee, which would be possibly speedier.

So there are probably margins for speeding up also Jython. OTOH I expect 
.NET to allow a larger range of tricks.

My pet peeves with .NET are that it does not garbage collect dynamically 
loaded code,
but maybe their are finally planning to support that, or will at some point.
And that there is a strong pressure (market numbers etc ...) to favor 
platform integration versus keeping the ported languages true to their 
original semantics.
(rather purist peeves). But considering things like Groovy on Java side 
maybe it is what people want. [ I think there is a tension between 
scripting the platform and having languages that can survive beyond the 
platform. OTOH given that covering with a portability layer the huge class 
libraries that come with .NET or Java is probably something people don't 
have time to, the point is rather moot and only of theoretical interest, 
OTOH I know of some few CPython/Jython projects using one or the other on 
different tier and reusing domain logic ]

.NET, Mono, Parrot, PyPy... funny times ahead. 

More information about the Python-Dev mailing list