>>> 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. > 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. 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? Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
