[Pythonmac-SIG] Python C extensions that depend on dynamic
bob at redivi.com
Mon Jan 12 04:29:54 EST 2004
On Jan 12, 2004, at 3:56 AM, Nicholas Riley wrote:
> On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote:
>> Well, it's pretty obvious they're not folders, so I wouldn't be
> Sure, but you're hardly typical.
Yeah, but most people have never seen a ".bundle" file or folder either
way, so that's why I used myself as the example.
>> Just as a semi-but-not-really-serious idea: I wouldn't complain if
>> they *were* folders (CFBundle-type-bundles) on the Mac. Think about
>> it, we could embed the particular version of Python and OS
>> compatibility matrix in the Info.plist, throw in some fun external
>> into Resources, put required dylibs/frameworks in Frameworks (and the
>> Python runtime could jigger the appropriate dyld incantations to make
>> them load properly), use a higher level plugin API then raw dyld,
>> whatever. It's a metadata party, and everyone is invited.
> As an optional thing this sounds fine, but flat MH_BUNDLE containers
> should be supported for equivalence with every other Python platform.
To further encourage people to built bundles by hand with the wrong
tools or linker flags? ;) I suppose it's necessary to maintain the
MH_BUNDLE aspect -- not because of "equivalence" -- but because some
useful software programs insist on Not Using Distutils (subversion, and
uh.. VTK maybe?).
>>> What's wrong with using '.so' as the extention?
>> .so probably implies MH_DYLIB? I don't really have a problem with
>> It's ".pyext" that I don't really like.
> .so doesn't seem to imply MH_DYLIB, especially given the example of
> Apache. There's no difference between dylibs and bundles under other
> OSes, "shared object" doesn't seem to me to connote one or the other.
It implies MH_DYLIB to me because when you're porting software, more
often than not, a ".so" on Linux is a ".dylib" in OS X, and even if
it's ported as a ".framework" it's still MH_DYLIB. Maybe it's just me.
Yes, I'm aware that other operating systems don't have separate header
layouts for "dynamically linked libraries" and "plugins"... I'm just
thinking statistically here, so that probably means I'm wrong.
> I don't have a huge problem with .so either, but I'd prefer something
> more specific like .pyext. Why are you against it?
I think .pyext is more confusing (or at least less aesthetically
pleasing) than .bundle for No Good Reason. I think .bundle would be
ok, because that's what Perl and Ruby use. In other situations,
.bundle is sometimes a plug-in bundle.. but in our case, Python
extensions are plug-ins, so the difference is only technical. As far
as I know, those are the only two other "Python equivalent"
interpreters distributed with OS X.. so we're all alone here. I don't
want to count TCL, and especially not Java, because it seems they're
smoking something we're not with regard to MH_BUNDLE vs. MH_DYLIB and
file name extension consistency.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040112/da5a3827/smime.bin
More information about the Pythonmac-SIG