Martin v. Löwis wrote:
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.
I was unaware indeed; thanks for pointing this out.
IIUC, it's not just an API emulation, but also an ABI emulation.
Correct.
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.
I think this somewhat strengthens the point I was trying to make: An
alternate implementation that tries to be API compatible has to consider
so many things that it is questionable whether making Py_INCREF/DECREF
functions would be any simplification.
It would actually have been helpful for us, but I understand that it
would be a big performance hit. The Ironclad garbage collection
mechanism is described here:
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_01_24.shtml#e1055
We artificially inflate the refcount of all objects that Ironclad
creates to 2 and hold a reference to them on the .NET side to make them
ineligible for garbage collection.
Because we can't always know when objects have been decreffed back down
to 1, there are some circumstances when we have to scan all the objects
we are holding onto. If their refcount is only 1 then we no longer need
to hold a reference them. When nothing is using them on the IronPython
side either normal .NET garbage collection kicks in and the IronPython
proxy object has a destructor that calls back into Ironclad and uses the
CPython dealloc method.
So I just ask:
a) Would it help IronClad if it could restrict itself to PEP 384
compatible modules?
b) Would further restrictions in the PEP help that cause?
I've forwarded these questions to the lead developer of Ironclad
(William Reade) along with a link to the PEP. He isn't on Python-dev so
I may have to be a proxy for him in discussion. His initial response was
"looks pretty sweet".
Michael
Regards,
Martin
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
--
http://mail.python.org/mailman/listinfo/python-list
