On Wednesday, Aug 6, 2003, at 00:12 Europe/Amsterdam, Francois Pinard wrote: > Last week, I had to recompile `vim' on many machines to enable Python > support, and this doubles the size of the installed binary. Here > again, > one might hypothesise that the Linux packagers (SuSE in this case) > would > have more naturally provided a Python-enabled `vim' if its size was not > bloating so evidently. > > Similar considerations might apply each time Python is considered as an > extension languages for a system written in another language, who > knows. > The system has to be pretty big to start with, for > Python-as-an-extension > to appear as something else than an enterprise. This is the main point, I think. By not including the shared library by default people looking for an extension language may decide to look elsewhere. MacPython has always had a shared library architecture on both MacOS9 and MacOSX (I think we can consider frameworks shared libraries for this discussion). Actually, the fact that Apple didn't ship the shared library with the Python 2.2 they included with MacOSX 10.2 caused headaches: there's funky workarounds with Python scripts for the fact that applets can't be linked against the python shared libraries. And mixing ObjC and Python is pretty much impossible. This is all solved for 2.3, through the framework build. -- Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
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