[Pythonmac-SIG] Re: Apple's install vs. a custom install of Python

[Bill Bumgarner]

If the goal is merely to render the best possible Python runtime 
environment on the planet, I agree with Alex's statement wholeheartedly.

While that is a motivator, it is not *my* goal for the Python on OS X 
and I hope it isn't the goal of this community (if it is, I'll go focus 
solely on PyObjC again like I did when OS X original shipped and the 
direction of the Python community was clear -- not that I thought the 
direction was wrong, it just wasn't right for *me*).

I am hoping that the goal is to allow third party developers to ship 
first class, standalone OS X applications that their customers can use 
and enjoy to the fullest extent that OS X and the developer's product 
provide.

Notice that the word "Python" does not come up in that sentence.   That 
is on purpose.   To achieve this goal, the end user should not be 
remotely aware that Python played any role in the construction of the 
application any more than they should care if Carbon or Cocoa was used!

To pull this off requires two things:

     - the end user of said applications does not have to install 
anything for the app to work;  the app wrapper (or installer, if the 
developer so chooses to go that route-- no reason to do so unless you 
are integrating something into the system) should be entirely self 
contained

     - the application should not be a gigantic hunk of bloatware.   
Both MacPython and Python 2.1 for OS X weigh in at more than 5MB -- 
that's before you have even thought about sticking the app specific 
stuff on it.

If the app requires some other component to be installed first, it'll 
seriously decrease the potential user base.   Most user's won't 
bother-- even if they do know how to go about finding and installing 
the appropriate components-- going through the trouble of doing so.   
Likewise, if the app is too bloated -- 20+MB for a simple note pad or 
RSS reader -- they aren't going to bother downloading and installing 
the thing, even with broadband.

As such, making sure that our lowest common denominator is the Apple 
installation of Python has a huge advantage in that I can ship a 500k 
application that happens to be implemented in Python-- though the end 
user won't know it-- instead of a 6+MB application and I can ship said 
application such that the installation doesn't require more than the 
ability to drag-n-drop to install.   No admin password.  No installer.  
Can be used by anyone.

This is exactly how PyObjC works.  Currently, because of the way the 
Apple python works, the launch times of the apps are slower than they 
should be.    However, I'm willing to bet that I would lose more users 
if it were 5mb vs. the 500k it is now or if it required the user to 
install some random package that required admin rights to install...

None of this is to say that effort should not be expended on a custom, 
standalone, python environment that can be installed that is 
significantly more capable than Apple's installation -- but, if that 
decision is made, it must be made with full  awareness of the change it 
implies regarding the target audience/consumer/customer/user.

b.bum

On Wednesday, October 23, 2002, at 03:23 PM, Alexandre Parenteau 
<alexp@strata.com> wrote:
> So augmenting the so called "Apple installation" has no appeal for me. 
> I
> would rather have *one* installation, which can extend beyond the 
> command
> line. And Apple will probably use it.