Re PEP 3149 file names: it hadn't struck me until fairly recently that PEP 3149-style extension file names were never implemented for OS X, i.e. they are still of the form _helperlib.so.  I'm not sure why that is the case since other aspects of PEP 3149-like file names do exist on OS X, including naming libpython; perhaps it was just erring on the side of caution.

Re bitness: As Marc-Andre points out, Apple addressed the multi-arch problem with the concept of universal (or "fat") binary files, implemented for executables, libs (static and dynamic), and bundles (e.g .so's).  In general, dealing with multiple architectures is abstracted away by the compiler tool chain at build time and the dynamic loader at run time and it's not something either Python or the user have to deal with (usually), as various combinations of architectures (currently up to 4 on OS X) are contained within the same file; for example:

$ file _socket.so
_socket.so: Mach-O universal binary with 3 architectures
_socket.so (for architecture x86_64):	Mach-O 64-bit bundle x86_64
_socket.so (for architecture i386):	Mach-O bundle i386
_socket.so (for architecture ppc7400):	Mach-O bundle ppc
$ file /usr/bin/python
/usr/bin/python: Mach-O universal binary with 3 architectures
/usr/bin/python (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/python (for architecture i386):	Mach-O executable i386
/usr/bin/python (for architecture ppc7400):	Mach-O executable ppc

So, I agree with Marc-Andre that adding arch info (like bitiness) to extension module file names on OS X would add unneeded complexity for little, if any, benefit.  That part works well today.  Changing builds on OS X to use today's PEP 3149 file names is a separate question.  It could help in the case where one site-packages library is used with multiple Python instances but, even there, that is probably not a big issue outside of developer environments: (1) I don't know of any distributor of Python for OS X who supports multiple ABIs (e.g. non-debug vs debug) in one package; (2) Python OS X framework builds, used by python.org, Apple, and most third-parties, generally have separate install locations including their lib-dynload and site-packages directories so installing multiple instances of the same Python version from different vendors isn't a big deal.  It would be nice to be able to allow non-debug vs debug builds to co-exist better (the primary use case I see for PEP 3149 file names for Py3 on OS X) but I don't recall anyone asking for it.  If we were to change OS X to use today's PEP 3149 file names, I would only want to do it in a new release, not backport it.