[Python-Dev] Any NeXT users out there?

[Jack Jansen]

> > The alternative is of course that we also provide a 
> > "--with-previous-framework". Any suggestions as to what it should do? :-)
> 
> Based on your current patch, I think it is save to remove any claim
> that this does something useful on the Next. It may do, but that would
> be purely coincidental.

That was a joke:-)

But seriously: if noone speaks up within the next couple of hours I will rip 
out NeXT support. I'll also add an option (--enable-toolbox-glue?) to rip out 
the glue code for MacPython/Carbon modules, thereby increasing the chances 
that this will all work on a bare Darwin without MacOSX.

> > On a high level it is a very nifty way to package a shared library
> > complete with all its supporting files. These supporting files range
> > from things used at runtime (like the python Lib directory) to the C
> > header files needed when you want to link against the library to the
> > documentation.
> 
> Ok. Then my question is: Why is it desirable to build libpython as a
> framework?

Sharing is the answer. When everything is finished an average Python user will 
have at least the interpreter application (the bundled drag-and-drop one) and 
the IDE installed. There may be auxiliary apps like the current MacPython's 
BuildApplet and BuildApplication. Eventually a slightly specialised 
interpreter that does the Cocoa/NIB magic on startup so that creating Cocoa 
apps in Python should be (almost?) as easy as creating them in ObjC or Java.

They may have the commandline interpreter too, if they're one of the 5% of mac 
users who aren't scared sh*tless by a command line. They may have Zope. They 
may have any of a number of other apps that are yet to be created that are 
implemented in Python.

> > Everything is in a single directory, so install/uninstall is a
> > breeze with no danger of missing things.
> 
> In case of Python, "everything" is the header files, and the .py
> library, right?

Yep. This is all you would need to either embed Python or extend it. So even 
for many developers there would be no reason to get a source distribution.
 
> Couldn't you also get this by making Python an Application Bundle
> (which you intend to do anyway)?

I've looked at that, but I don't think you can get the sharing explained above 
by that. Also, the development tools all know about frameworks, and if we'd 
want to pick stuff up from an application bundle we would have to hand-craft 
things.

> > Also, the structure of a framework allows you to have older,
> > incompatible versions of the library (and support documents) in the
> > framework as well, with these older versions only used by programs
> > that were linked against the framework when that version was
> > current.
> 
> Again, why is that desirable? If you have multiple versions of Python
> installed, if each version has libpython linked statically, and comes
> with its own set of header files and .py files: there wouldn't be any
> older, incompatible versions of the library that you may need to
> defend against.

You shouldn't really be thinking "multiple versions of Python" here but 
"multiple products which are implemented with different versions of Python". 
Think of the sort of things RealBasic can do, allowing end-users with a little 
programming experience create fullblown applications they can distribute. 
That's where I would like Python on OSX to go. And iff we get the ObjC stuff 
revived and make it work together with Cocoa then those end users can use 
Interface Builder to create their UI, so they main piece of functionality that 
Python misses when compared to RealBasic, the guibuilder, is provided for us 
by Apple.

> You may wonder why I question that feature so much. To me, it is
> similar to building a shared libpython.so on Unix. I think this will
> cause many problems, and in no way it should be done just for a single
> platform (there were patches to do this for Linux, I believe, and such
> a patch to make it work specifically on UnixWare only even made it
> into 2.1). I think it is desirable that the feature "shared libpython"
> is implemented as uniformly as possible across systems. 
> 
> If Mac OS X wants to do it differently from everybody else, you need a
> very good reason.

This is probably the crux of your reasoning, and I think I disagree. For one, 
MacOSX (ok, OpenStep is where they got it from) is the first unix-based system 
that I'm aware of that seems to have a solution to the versioning problem. All 
unixes that I know simply stick a version number in the .so filename and leave 
it at that, and the only reason dll-hell hasn't hit unix as hard as Windows is 
because it's deployed a lot less, used by more knowledgeable people and 
Microsoft doesn't get to touch it. But the problem is essentially there. Now 
that MacOSX has a versioning system we should put it to good use. And maybe 
we'll like it so much that we can use it for all Pythons.

Also, while I would like Python to be a model MacOSX citizen I'm also trying 
hard to make it as good a Python community citizen as it can be, so I'm 
putting a 100% compatible unix Python installation into the framework. Not 
only will this make pythonistas with a unix background feel at home, but it 
should also mean that there's no extra code needed in distutils and all the 
other stuff that knows what a Python installation looks like.

> The only platform that already has a shared pythonXY.dll has a good
> reason: you cannot export symbols from the application to extension
> modules on Windows. Yet, this is also the only platform where the API
> version magic is meaningless, since extension modules break with every
> new Python version exactly because libpython is shared.

The same is true for MacPython, and also true for Python on MacOSX. But 
whereas with MacPython extension modules also broke every single release (even 
if only because the underlying C library was a moving target) with MacOSX I 
think we can do a bit better. The only thing to work is is exactly how to put 
version numbers to good use, because extension modules linked against Python 
will be interested primarily in the API version number but applications using 
Python will be interested primarily in the 2.2-style version number, and I'm 
not sure yet how to work that out. Maybe prepending the API version number (so 
the full version would becomes something like "1011.2.2) will work.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm