[Python-Dev] Any NeXT users out there?

[Martin v. Loewis]

> I'm unsure, I've never fully understood the intention behind --with and 
> --enable. For instance, why is it "--enable-unicode" and "--with-threads"?

I think the eventual choice is yours, given Guido's objections to
gettext manual; my objections where primarily backed by this manual.

> 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.

> 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? You give some rationale below, but I fail to see the
point. I'll pick what I think are your arguments to build a Python
framework, and try to see what it gives to the end user - compared to
the option of linking libpython into the Python interpreter.

> 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?

Couldn't you also get this by making Python an Application Bundle
(which you intend to do anyway)?

> 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.

> The framework patch in sourceforge is the first step. The next step
> is to create a Python application bundle. We can then use a single
> trick in the Python main() program, where it will check to see
> whether it's being run from an application bundle and, if so,
> whether there's a magic file in the bundle (__main__.py comes to
> mind). If there is Python will run that file as the script. This
> will give Python users "freeze" functionality without using a
> compiler.

For that second step, do you really need the first one? I agree that
'freezing' Python applications by just putting a Python installation
into a subdirectory is cool (if I understand right how such a frozen
application would work), however, I fail to see the role of the
framework in here.

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.

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.

Regards,
Martin