On Wednesday, September 25, 2002, at 01:51 PM, Ronald Oussoren wrote:
> On Tuesday, Sep 24, 2002, at 19:48 Europe/Amsterdam, Bill Bumgarner
> wrote:
>> In all, it solves a different problem than the problem presented by
>> the goal of creating standalone fully Cocoa compliant applications.
>> Namely, PythonLauncher is much more about invoking a particular
>> script and much less about distributing a standalone ".app" that a
>> user can simply double-click to use.
>
> Could you please rename your PythonLauncher, two applications with the
> same name is pretty confusing. To illustrate this: The
> 'PythonLauncher' you mention above is probably Jack's version, not
> yours but I'm not entirely sure...
Oh, I suppose -- I mean, my PythonLauncher was actually a quickie hack
posted to python-mac to answer some questions about how to write a
PythonLauncher type thing. I even cc'd Jack on the original...
But, he beat me into the repository, so the name is his. :-)
The above referred to Jack's app.
(In all seriousness, yes-- the name should and will be changed if I get
around to writing a replacement for the existing [Jack's]
PythonLauncher).
> Just to make things clear: Is your PythonLauncher meant to be a binary
> that can be dropped in a '.app' directory to create a python-based
> application?
Nope -- that is a completely different app/problem. More info later
today.
>>> BTW. I'd prefer to have a framework install of python as the
>>> standard python sometime in the future. Maybe in MacOSX 10.4........
>>
>> I would rather see Python remain as open and cross platform
>> compatible as possible. In that context, a framework (or bundle)
>> might be an appropriate means of encapsulating resources specific to
>> the Macintosh extension modules. I.e. the mac specific (OS X,
>> really) resources would be shoved into PyMac.framework down in
>> site-packages (assuming the macintosh support were to remain as a
>> module).
>>
>> However, encapsulating all of python into a framework doesn't
>> really add anything to the environment in terms of features and
>> definitely makes for a weird twist when using the Mac platform.
>
> This is probably something that should be discussed on the
> Python-on-Mac SIG, but what the heck...
We can go there once we have hashed through it a bit here...
> I definitely do not like a partial framework (the unix install
> containing a PyMac.framework for Mac specific stuff). That would be
> both confusing and reduce cross-platform compatibility (e.g. how
> should distutils cope with that?).
>
> Like you said, the framework install doesn't really add new features.
> However, I also feel that it doesn't hamper cross-platform
> compatibility and openess. If you replace /usr/bin/python by a symlink
> to the python inside a framework install the resulting situation is
> completely compatible with the current situation.
If it doesn't add any features, then why add all of the
administrative/maintenance overhead to the core python project that is
necessary to support it?
Looking at the piles and piles of patches required in configure, the
various makefiles, and an entire subdirectory full of gunk that is
special cased into the framework build, it seems that the framework
build is already hampering cross-platform compatibility in that it
requires so much extra effort to make python work on the Mac platform
[assuming a framework build is a part of supporting the Mac platform].
Anything that unnecessarily makes the Macintosh support behave
differently than, say, bsd/sun/linux hampers cross platform
compatibility.
>
> The reasons I like the framework approach are twofold. First of all
> frameworks are the method Apple is pushing for publishing library-type
> stuff (and I like to think of the python interpreter as a complicated
> type of dynamic loader :-)). But more importantly, a framework install
> makes it more clear that Python is not just tool for 'unix weenies'
> but something you can use for real work.
Apple pushes framework based encapsulation of things that are libraries
for reusable code specific to the platform, not for reusable/libary
code that is made available across many platforms. Looking at the
system (and Darwin), the only exception is the readline framework.
Looking /usr/lib/ reveals that Apple is very much pushing for a build
model for portable code -- libz, termcap, ruby, perl, python, tcl,
crypto, pthreads, etc... -- that requires as few changes as possible
between OS X/Darwin and any other Unix derived platform.
IMO, this is a wise decision -- it reduces the amount of maintenance
necessary on the part of Apple and third party developers to achieve
continued first class support for these tools on the platform.
Whether Python is in a framework or as a regular "command line" tool
will do little to attract or deter non "unix weenies" from using it.
We will be able to attract many more developers by supporting and
providing examples for doing Python development in PBX using the
out-of-the-box python on OS X.
Certainly, having a Python IDE and the ability to run individual
scripts from, say, the Finder will help, but having to
rebuild/reinstall Python to gain access to that capability will deter
many. Given the rather crufty implementation of said solutions--
Carbon is legacy and at a completely different granularity than Python
or Cooca-- quite a few more developers will be deterred.
>
> BTW. I'm a Unix weenie myself and most (Python) code I write at the
> moment has to do with either command-line scripts or webbased stuff.
> The framework install of Python I have at my machine is perfectly
> useable for this.
Perfectly usable, yes, but it adds a boatload of additional maintenance
cost and installation headache to the core python codebase. The
framework based build of Python has existed since the NeXT days along
with a number of unnecessary, platform specific, modifications to the
core codebase to support NeXT and it has been a constant source of
headaches. The end result is that the version of Python on NeXT and,
now, OS X has typically lagged behind the version available on other--
more mainstream-- platforms by anywhere from days to months.
Certainly, OS X's popularity will reduce that gap, but why have a gap
if it can be avoided entirely and comfortably?
Furthermore, the chances of Apple shipping a framework build of python
as a part of the system are pretty slim as the framework build of
python doesn't add much to the capabilities of the language and incurs
a bunch of additional maintenance/support headaches for Apple (i.e. do
they have to ship a separate version for, say, Darwin??).
Not that Carbon support in Python does not require the framework build
-- it is just the extended Mac Python IDE / Dev environment that
requires the framework (mostly because the build of it is currently
quite broken).
>
> Back to making Python the best development tool on MacOS X,
>
> Ronald
>
> P.S. Don't let this keep you from improving PyObjC for users of the
> Apple-distributed Python ;-) ;-)
I think of Python + Cocoa via PyObjC as being at the same level as,
say, AppleScript Studio. Python provides the high level, easy to
author, development language similar to AppleScript (though easier)
while PyObjC provides the glue into the Cocoa frameworks. Frankly,
given the comparative cleanliness with which Python interacts with ObjC
across the PyObjC bridge, the Python solution is a hell of a lot
simpler and easier to deal with than AppleScript Studio -- not a
criticism of Studio, just the realities of building AppleScript based
development tools.
The proof is in the code -- I'm going to stop blathering now and
actually put together a proper / easy recipe for creating Python based
Cocoa apps and commit that into the repository...
b.bum
|