[Pythonmac-SIG] Some thoughts on Python and OS X

Kenneth McDonald kenneth.m.mcdonald at sbcglobal.net
Mon Jun 14 01:28:25 EDT 2004


The following comes from some experiences I've had recently whilst
wrangling with wxPython/SPE, plus some others encountered in the
past while doing custom installs of Tk and tkinter. I don't want to 
start
any flame wars, and I certainly don't want to hurt any feelings--the 
Python
people at Apple are doing a great job, and I really appreciate their
effort. However, the "Apple Philosophy" as applied to Python (and
indeed as applied to much of the UNIX subsurface in OS X) is making
things painfully, and in my opinion unnecessarily, difficult to use.

First, the obvious: Having a "required, custom" build of Python on
OS X is a Bad Idea. Last I heard, this was the official OS X way of
doing things, i.e. the Python you got was what you should use, don't
try replacing it, and no, it's not a stock Python. I believe this has 
been
recognized to be a problem and is being worked on--sorry if I'm
ignorant of recent fixes, I "threw out" the stock OS X Python some
time ago, as I needed my own custom compilations.

In general (and I'm sure the Apple techs understand this, but perhaps
you could pass this on to those in management who don't?), DON'T
EVER take a community standard tool such as Python and "improve"
it in such a manner as to make it incompatible with what people have
come to expect. If you must produce an Apple-specific version which
requires special consideration when being used with other packages,
then observe the following:

	1) The _standard_ version should be the standard; even on OS X.
	People who want to use Python without caring about the OS its
	on will then be able to use it properly. Those who want to make use
	of the os-enhanced version will know what to do.

	2) Make sure that an 'enhanced' version can coexist peacefully with
	the standard version.

One of the things that is expected is that I can download, compile,
and install a more recent version of Python without problem (assuming
the newer version itself doesn't have problems.) Another is that
add-ons for Python which have been written to install nicely in a
generic UNIX environment should continue to do so under OS X.

Next, paths. I can understand why Apple (actually, probably NeXT)
decided to come up with improvements on the UNIX file structure.
But why, oh why, couldn't they have maintained some sort of backward
compatibility using links? I've effectively recreated my own UNIX file
structure using links, to make up for this, and would be surprised if 
others
haven't as well. In particular, why the heck isn't there the equivalent 
of
/usr/local? Having this basic de facto standard sort of file structure 
in
place would save us UNIX software users countless hours in headaches.
Yes, it's easy to argue that the problems are the fault of bad 
installation
scripts and makefiles. Well, yes, in theory that's probably true; but so
what? The point of software is to be a useful tool, not to drive the 
customer
crazy by insisting that somebody else, in assuming a de facto standard 
of
the time would continue into the future, made a mistake.

I find this a particular problem when it comes to Frameworks and 
Libraries.
Here's a typical example of installing a couple of Python modules 
recently:

1) Compile module A--works, great. Install it. Where the heck are the
files? Do a search on the disk. Ah, there they are in
/Library/Frameworks/Python/.../.../... and so on .../2.3/site-packages.
Create a link from a more reasonable location so they'll be on the
python path.

2) Compile and install module B. Where is it? Disk search. Ah, it's in
/Library/Python/2.3. Create link. Why did it end up here, vs. Module
A in Frameworks? Beats me.

And why, for that matter, are all of these modules always ending up in
a '2.3' directory? I happen to know that some of them aren't dependent
on the Python binary, and it looks to me as if, when 2.3 changes to 2.4,
I'm gonna have some unnecessary work, again. Trust me, if a module
is incompatible with 2.4, I'll know it soon enough; you don't have to
force me to move everything manually to the 2.4 path.

None of this is going to make me move off of OS X, of course; it still
is, by far, the best OS for most users IMHO, myself included. But this
situation will cost Apple some money; I generally keep fairly up-to-date
with hardware, and was planning on getting a new Powerbook when
they hit 2 GHz. However, I've had to do so much manual tweaking to my
system that the effort needed to recreate that on a new drive is a 
little too
much to want to repeat in the forseeable future, so Apple's probably 
going
to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know
I don't have to do a "clean" install of everything when I go to a new 
system,
but that's one of the things I do to help me clean all the cruft out.)

I'm looking forward to what comes out in the future, I have a lot of
confidence in the Python people at Apple, and I have no problems at
all in continuing to pay for new versions of OS X which bring new
features and improvements. I just hope that the above is of some help
in deciding how some of those features should be implemented in the
future.

Thanks,
Ken McDonald




More information about the Pythonmac-SIG mailing list