Python does not play well with others

Paul Boddie paul at boddie.org.uk
Thu Jan 25 07:07:22 EST 2007


On 25 Jan, 12:01, "Ben Sizer" <kylo... at gmail.com> wrote:
>
> Python is quite capable in many areas, such that the people in the
> community with the expertise to extend the language and libraries, are
> usually the ones who've been happily using the polished features for
> years and have found they need nothing more. And the ones who need
> those features probably got bored of waiting for progress long ago. You
> get the responses you do from years of natural selection in the
> community. 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. For
example, how would one update the cgi module? Since lots of code
including various Web frameworks makes use of the cgi module, it can't
just go away or have its APIs changed radically, but this doesn't
exactly make for a pretty "out of the box" solution for Web
programming. Someone else was complaining recently about URL handling
and the required combination of urllib, cgi and urlparse (or perhaps
some other combination, depending on what one's needs are). Presented
with the problem of rationalising all this, the chosen solution (as
adopted by the Web-SIG) is, as it is frequently, to ignore the problem
and to work on other things instead.

> People can say, "if you want it done, why aren't you doing it?", and is
> a fair question, but it doesn't alter the fact of Python's deficiencies
> in certain areas when compared with other languages.

True. It also doesn't address the issue of development priorities and
their role in defining the platform's own standards. We all know that
the Python language has issues (or "warts" as they are popularly
called), although some of the most notable ones don't seem to have been
addressed as yet in the plans for Python 3000 (eg. default argument
evaluation), but some of the most awkward aspects of using Python
involve libraries, not some deficiency of the language. However,
reforming the standard library is a topic which has arisen in all
seriousness only recently in the Python 3000 process (PEP 3108), and
the scope of the related activity is highly restricted - it's almost an
afterthought. Where the "why aren't you doing it?" part comes in
involves the observation that even if someone is motivated enough to
take something like this and to move forward in their own direction
[1], unless such initiatives are embraced by the core developers they
will remain peripheral, non-standard extensions that will at best only
become mainstream much later on.

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.

Paul

[1]
http://wiki.python.org/moin/CodingProjectIdeas/StandardLibrary/RestructuredStandardLibrary




More information about the Python-list mailing list