On May 16, 2010, at 02:21 PM, Piotr Ożarowski wrote: >What's missing to have full PEP3147 support? >* PEP 384 implementation (will allow us to share (most?) .so files)
I have a concern about this. While I understand the motivation, I'm not sure implementing PEP 384 will have any practical help in any kind of reasonable time frame. The reason being, that I think it's highly unlikely existing extension modules will be rewritten to use the ABI, or if they do, it will be a long time coming. Now perhaps I'm wrong, and that having the ABI available in Python 3.2 will make it so that anybody porting their extension module to Python 3 will naturally use it, and it will be a good opportunity to adopt the ABI. But I also think developers are (rightly!) lazy and will do the minimal amount to port their code, which will not include using the ABI. Of course the old adage of "there's more new code unwritten than there is existing code" will eventually come to our rescue, but again, not in any time frame that will be useful for us (maybe when my son is the FLUFL :). Matthias has also suggested getting the ABI version number in the .so filename and making the dynamic loader more intelligent. Kind of like a PEP 3147 for shared libraries. That would still mean we'd need to ship multiple .so's for every supported Python, so we'd lose the disk space/bandwidth advantage, but it might make for less hacky solutions to finding the right .so to load. I don't know. I'm skeptical that PEP 384 is worth the effort, but I'm open to other opinions. -Barry
signature.asc
Description: PGP signature
