[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