Python does not play well with others

[John Nagle]

Paul Boddie wrote:
> On 25 Jan, 12:01, "Ben Sizer" <kylo... at gmail.com> wrote:
> 
>> I think that is why many of the SIGs are stagnant, why the standard library
>> has so much fluff yet still lacks in key areas such as multimedia and web
>> development, etc.
> ... I think this is also a good insight into why things are as they are 
> within the core development section of the community, although one can wonder
> what some people actively developing the language are actually doing with it
> if they are satisfied with the state of some of the standard library
> solutions. However, there are lots of factors which motivate people and the
> proliferation (or otherwise) of solutions to common problems: whether one
> develops one's own solutions as separate projects and/or tries to push for a
> consensus, whether one cares about other people using such solutions, whether
> one aspires to contributing to the standard library.
> 
> Over the years, people have tended towards building their own communities
> around their projects rather than attempting to engage the wider Python
> community, and I think a motivation behind that has been the intractability
> of improving parts of the standard library.

    Yes.  Working on "frameworks" is perceived as cooler than working
on libraries.  Things like Ruby on Rails, Struts, Zope, and Twisted
get attention.  There are papers and conferences on these things.
It's hard to get people excited about overhauling
the CGI library, or making mod_python work securely in shared-hosting
environments.

    The key distinction between a framework and a library is that users
are expected to make their code fit the framework.  In particular,
frameworks aren't expected to play well with each other.  If you need
something from Zope and something from Twisted, you're probably not
going to be able to make it work.  Libraries, on the other hand,
are expected to play well together.  Which means that they have to
handle the hard cases correctly, not just the easy ones.

> True. It also doesn't address the issue of development priorities and their
> role in defining the platform's own standards
...
> I do wonder whether the interests of language/runtime project developers
> eventually become completely aligned with the needs of such projects, making
> things like "multimedia and web development" seem irrelevant, uninteresting
> or tangential. This has worrying implications for the perceived relevance of
> Python with regard to certain kinds of solutions, despite the wealth of
> independently produced libraries available for the language.

    Something like that happened to the C++ standards committee.
The committee was captured by the template fanatics, and most new
standards work involves doing computation at compile time via template
expansion.   That's seldom done in production code, yet most of the
standards effort is devoted to making cool template hacks work better.
Meanwhile, real problems, like doing something about memory leaks and buffer
overflows, are ignored by the C++ committee.  As a result, C++ is
being displaced by Java and C#, which don't have elaborate templates but do have
memory safety.

    I'm not sure how the Python development community will deal with this
problem.  But what's happened in the C++ standards world has clearly
been very bad for users of the language.  Learn from the mistakes there.

    My main concern is with glue code to major packages.  The connections
to OpenSSL, MySQL, and Apache (i.e. mod_python) all exist, but have major
weaknesses.  If you're doing web applications, those are standard pieces
which need to work right.  There's a tendency to treat those as abandonware
and re-implement them as event-driven systems in Twisted.  Yet the
main packages aren't seriously broken.  It's just that the learning curve
to make a small fix to any of them is substantial, so nobody new takes
on the problem.

				John Nagle
				Animats