Mailing List Archive: ISPs and Python

ISPs and Python

Jul 15, 1999, 3:29 PM

Post #1 of 3 (875 views)

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 :-)

See attached c.l.py post.

This is similar to the evolution of Python's name recognition -- used
to be, managers would say "what's Python?"; then they said "nobody
else uses Python"; now presumably they will have to make up some kind
ad-hoc no-Python company policy :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)
------- Start of forwarded message -------
From: Sim & Golda Zacks <simngolda@voyager.net>
Newsgroups: comp.lang.python
Subject: Re: htmllib, cgi, HTMLfmt, genCGI, HTMLgen, html, Zope, ...
Date: Wed, 14 Jul 1999 00:00:25 -0400
Organization: ExecPC Internet - Milwaukee, WI
Message-ID: <7mh1qu$c6m@newsops.execpc.com>
References: <tot2m7.su.ln@final.math.uni-bonn.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am in the exact same situation as you are. I am a web programmer and I'm
trying to implement the CGI and database stuff with Python. I am using the
HTMLFMT module from the INTERNET PROGRAMMING book and the cgi module from the
standard library. What the HTMLFMT library does for you is just that you don't
have to type in all the tags, basically it's nothing magical, if I didn't have
it I would have to make something up and it probably wouldn't be half as good.
the standard cgi unit gives you all the fields from the form, and I haven't
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
ones I talked to, refused to install the mysql interface to Python, and it has
to be included in the build (or something like that) So I just installed gadfly,
which seems to be working great for me right now. I'm still playing with it not
in production yet.
I have no idea what ZOPE does, but everyone who talks about it seems to love it.

Hope this helps

Sim Zacks

[...]

------- End of forwarded message -------

RE: ISPs and Python [ In reply to ]

mhammond at skippinet

Jul 15, 1999, 4:21 PM

Post #2 of 3 (863 views)

Permalink

> 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.

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 :-)

of-course-you-should-all-do-that-while-I-continue-to-hack<wink>-ly,

Mark.

Re: ISPs and Python [ In reply to ]

mal at lemburg

Jul 16, 1999, 12:44 AM

Post #3 of 3 (853 views)

Permalink

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/