On Jun 24, 2010, at 10:48 AM, Brett Cannon wrote: >While the idea is fine with me since I won't have any of my >directories cluttered with multiple .so files, I would still want to >add some moniker showing that the version number represents the >interpreter and not the .so file. If I read "foo.3.2.so", that naively >seems to mean to mean the foo module's 3.2 release is what is in >installed, not that it's built for CPython 3.2. So even though it >might be redundant, I would still want the VM name added.
I have a new version of my patch that steals the "magic tag" idea from PEP 3147. Note that it does not use the *actual* same piece of information to compose the file name, but for now it does match the pyc tag string. E.g. % find . -name \*.so ./build/lib.linux-x86_64-3.2/math.cpython-32.so ./build/lib.linux-x86_64-3.2/select.cpython-32.so ./build/lib.linux-x86_64-3.2/_struct.cpython-32.so ... Further, by default, ./configure doesn't add this tag so that you would have to build Python with: % SOABI=cpython-32 ./configure to get anything between the module name and the extension. I could of course make this a configure switch instead, and could default it to some other magic string instead of the empty string. >Adding the VM name also doesn't make extension modules the exclusive >domain of CPython either. If some other VM decides to make their own >.so files that are not binary compatible then we should not preclude >that as this solution it is nothing more than it makes a string >comparison have to look at 7 more characters. > >-Brett > >P.S.: I wish we could drop use of the 'module.so' variant at the same >time, for consistency sake and to cut out a stat call, but I know that >is asking too much. I think you're right that with the $SOABI trick above, you wouldn't get the name collisions Guido recalls, and you could get rid of module.so. OTOH, as I am currently only targeting Linux, it seems like the module.so stat is wasted anyway on that platform. -Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
