Paul Rubin wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > > > Since Python is being touted as good for web apps as a competitor to > > > PHP > > > > Python is being touted as a good language for *many* purposes, not > > just web applications. Python is also a "competitor" to Java, to Ruby, > > to Perl, to many other languages. They all have strengths and > > weaknesses. > > Yes but in the cases where Python's weakness compared with one of > those other languages is lack of library functionality, if Python can > remedy the weakness by incorporating similar functionality into its > library it should do so.
Python should only incorporate functionality in order to offer a coherent experience (where the omission of functionality would otherwise lead to a flawed experience). For example, having support for SSL in the socket module offers a coherent experience because it means that urllib and related modules can offer to support SSL-related URLs out of the box. That said, there's probably a case for better library design and having things like SSL-related "protocol handlers" be available as plugins, detected and integrated in some kind of framework, although this would bring in configuration issues of its own. [...] > > > I'm paying the hosting company for access to a computer that's > > > connected to electricity and to the internet and which has a > > > straightforward OS, language package, web server, and db installed. > > > > In which case, there should be no problem with *you* installing > > whatever software you need to use the system for what you want. > > No. That would be colo or something similar , where I'm basically > paying for bare metal plus electricity and network, and I'm completely > in charge of the software. Or a virtual private server. > Web hosting means the ISP is in charge of all the software except for my > application (i.e. they handle the OS, > language package, web server, and db, as described above). So they > run (typically) Linux, MySQL, Apache, and PHP; and I get to upload my > own PHP apps and use the PHP library. That's a lot less work for me > since I don't have to stay on top of kernel patches or firewall > configuration, and it's cheaper because they host a bazillion sites > (virtual hosts) in a a single server instance. That's known as "shared hosting" these days, I believe. The advantage of shared hosting is arguably convenience for everyone concerned: the provider has a static configuration; the users have the stability of a managed system. However, this only works for people whose needs are met with that configuration, obviously. The big thing for people wanting decent Python support in shared hosting environments (aside from complaints about process isolation) is whether it's easy or obvious enough for providers to make configurations that Python people would actually use. Probably the biggest inhibitor, as far as I can see, has been the server technology chosen. Many hosting providers have historically offered no better than CGI for Python, whilst PHP runs within Apache itself, and it has previously been stated that mod_python has been undesirable with regard to isolating processes from each other. Consequently, a number of Python people seem to have held out for other "high performance" solutions, which various companies now offer. > > > They shouldn't have to deal with dozens of interdependent modules > > > downloaded from different places just to support one language. > > > > Either they are providing far more than the minimal set you describe > > above, or this is entirely outside their domain. Make up your mind. > > No it's you who's got it wrong, I just described above what they're > doing. Do you actually use any services like this? If a hosting provider claims Python and MySQL support, then I'd hope that they have worked out that the MySQLdb package glues the two together. Perhaps better information is necessary for those hosting companies who haven't worked such things out: you'd have a metapackage for stuff like this in certain distributions. > > You can't claim both that the hosting company should have to maintain > > a comprehensive set of functionality, *and* that they should not have to. > > They should get a distro that includes a lot of stuff, type "make", > and all the stuff becomes available to their users. So, for the less forward-thinking providers a metapackage would be the solution, then? Paul -- http://mail.python.org/mailman/listinfo/python-list