[Python-Dev] ISPs and Python

M.-A. Lemburg mal@lemburg.com
Fri, 16 Jul 1999 09:44:20 +0200


Mark Hammond wrote:
> 
> > Remember the days when the big problem was to find an ISP who would
> > install Python?  Apparently that problem has gone away...  The problem
> > is now to get one that installs a decent set of Python extensions :-)
> 
> he he.  Yes, hence I believe the general agreement exists that we should
> begin to focus on these more external issues than the language itself.
> Pity we all agree, but are still such hackers :-)
> 
> > looked at the cgi modules from the book yet to see if they
> > give me any added
> > benefit. The big problem I came across was my web host, and
> > all of the other
> 
> >From the ISP's POV, this is reasonable.  I wouldnt be surprised to find
> they started with the same policy for Perl.  The issue is less likely to be
> anything to do with Python, but to do with stability.  If every client was
> allowed to install their own extension, then that could wreak havoc.  Some
> ISPs will allow a private Python build, but some only allow you to use
> their shared version, which they obviously want kept pretty stable.
> 
> The answer would seem to be to embrace MALs efforts.  Not only should we be
> looking at pre-compiled (as I believe his effort is) but also towards
> "batteries included, plus spare batteries, wall charger, car charger and
> solar panels".  ISP targetted installations with _many_ extensions
> installed could be very useful - who cares if it is 20MB - if they dont
> want that, let then do it manually with the standard installation like
> everyone else.

mxCGIPython is a project aimed at exactly this situation. The only
current caveat with it is that the binaries are not capable of
loading shared extensions (maybe some linker guru could help here).
In summary the cgipython binaries are complete Python interpreters
with a frozen Python standard lib included. This means that you
only need to install a single file on your ISP account and you're
set for CGI/Python.
 
More infos + the binaries are available here:

	http://starship.skyport.net/~lemburg/mxCGIPython.html

The package could also be tweaked to include a set of common
extensions, I suppose, since it uses freeze.py to do most of the
job.

> There could almost be commercial scope here for a support company.
> Offering ISP/Corporate specific CDs and support.  Installations targetted
> at machines shared among a huge number of users, with almost every common
> Python extension any of these users would need.  Corporates and ISPs may
> pay far more handsomly than individuals for this kind of stuff.
> 
> I know I am ranting still, but I repeat my starting point that addressing
> issues like this are IMO the single best thing we could do for Python.  We
> could leave the language along for 2 years, and come back to it when this
> shite is better under control :-)

Naa, that would spoil all the fun ;-)

But anyways, going commercial with Python is not that far-fetched
anymore nowadays... something like what the Linux distributors
are doing for Linux could probably also be done with Python.

Which brings us back to the package name topic or better the
import mechanism...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   168 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/