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 -------
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
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/
participants (3)
-
Guido van Rossum -
M.-A. Lemburg -
Mark Hammond