> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4