Martin v. Löwis wrote:
Dino Viehland wrote:
Dirkjan Ochtman wrote:
It would seem to me that optimizations are likely to require data
structure changes, for exactly the kind of core data structures that
you're talking about locking down. But that's just a high-level view,
I might be wrong.
In particular I would guess that ref counting is the biggest issue here.
I would think not directly exposing the field and having inc/dec ref
Functions (real methods, not macros) for it would give a lot more
ability to change the API in the future.
In the context of optimization, I'm skeptical that introducing functions
for the reference counting would be useful. Making the INCREF/DECREF
macros functions just in case the reference counting goes away is IMO
an unacceptable performance cost.
Instead, such a change should go through the regular deprecation
procedure and/or cause the release of Python 4.0.
It also might make it easier for alternate implementations to support
the same API so some modules could work cross implementation - but I
suspect that's a non-goal of this PEP :).
Indeed :-) I'm also skeptical that this would actually allow
cross-implementation modules to happen. The list of functions that
an alternate implementation would have to provide is fairly long.
Just in case you're unaware of it; the company I work for has an open
source project called Ironclad. This *is* a reimplementation of the
Python C API and gives us binary compatibility with [some subset of]
Python C extensions for use from IronPython.
http://www.resolversystems.com/documentation/index.php/Ironclad.html
It's an ambitious project but it is now at the stage where 1000s of the
Numpy and Scipy tests pass when run from IronPython. I don't think this
PEP impacts the project, but it is not completely unfeasible for the
alternative implementations to do this.
In particular we have had to address the issue of the GIL and extensions
(IronPython has no GIL) and reference counting (which IronPython also
doesn't) use.
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
--
http://mail.python.org/mailman/listinfo/python-list
