Python does not play well with others

[Paul Boddie]

Paul Rubin wrote:
> Ben Finney <bignose+hates-spam at benfinney.id.au> 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