Python does not play well with others

[Paul Rubin]

"Paul Boddie" <paul at boddie.org.uk> writes:
> 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. 

But they can't, because the built-in socket module SSL interface
doesn't check certificates, causing total security failure if someone
spoofs the remote site.  The built-in SSL functionality is broken and
users have to resort to external packages.

Then you have to ask why the stdlib includes anything like urllib in
the first place, under this "coherent experience" concept (I interpret
that as some kind of minimalist philosophy).  Can't users have a
coherent experience if the stdlib doesn't include urllib?  My own
answer is the one that I thought that the developers had settled on
years ago, namely "batteries included", i.e. ship a rich set of
libraries that provide a wide variety of useful functions, i.e. the
doctrine of minimalism has been explicitly rejected.  We then get the
question of whether to include any specific function and that's where
comparisons with other languages come in.

> > No.  That would be colo or something similar ,
> Or a virtual private server.
Sure, that would count as "something similar".

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

I'd expect so too.  The issue is there aren't very many of those
companies and that appears partly because of the hassle involved.  So
minimizing the hassle suggests itself as a road to wider acceptance.

Your point that shared hosting with Python isn't so easy because of
insufficient isolation between apps is valid.  Maybe Python 3.0 can do
something about that and it seems like a valid thing to consider while
fleshing out the 3.0 design.

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

That could help.

> So, for the less forward-thinking providers a metapackage would be the
> solution, then?

I'm not sure what you mean by metapackage but in general the goal is
to minimize the number of places that the hosting provider (or OS
distro maintainer, or whatever)