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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4