PEP scepticism

[Paul Boddie]

"Tim Peters" <tim.one at home.com> wrote in message news:<mailman.993957902.3207.python-list at python.org>...
> [Carlos Ribeiro]

[...]

> > - Define clearly what goes and what does not go into the standard
> > library.
> 
> This is the province of PEP 2:
> 
>     http://python.sourceforge.net/peps/pep-0002.html
> 
> While what's there is fine so far as it goes, it would help if someone added
> a second sentence <wink>.

Whilst the PythonLabs people have had firm control over the standard
library when it comes to finalising releases (deciding which modules
to discard, which to obsolete, and which to include), there doesn't
seem to be any source of authority when it comes to directing the
development of new-but-important modules. The SIGs are interesting to
read now and again but, as you or someone else pointed out, they don't
always necessarily produce much as a side-effect - they certainly
don't have the same output/talk ratio that "independent" projects
have.

> > - Help track the module development process.

Where this crosses over into the "Is Python dead?" thread is possibly
in the area of people wanting clear and reliable advice on how to
proceed with development work in certain domains, along with pointers
to where they can best help out. One might suggest that interested
parties read the documentation, trawl Sourceforge, or join various
lists, but it would be a compelling idea that someone could just visit
the currently rarely-updated python.org site, see the "hot projects",
access the "Web application recipes" or the "database application
cookbooks" and more easily participate.

Of course, it doesn't have to be python.org where this happens, and
there are numerous examples of sites which attempt to address these
issues. Freshmeat and Sourceforge, for example, have certain
interesting concepts such as indications of activity levels in
projects. I'm sure that such concepts could be applied to the
Parnassus in order to increase the usability of that site even
further. However, this doesn't really go far enough - I think people
want to be guided, possibly by members of Python's "trusted elite" to
activities that would benefit most from their participation.

> > - Compile the standard modules for all supported platforms.
> 
> Good goal, but no way to get there from here:  PythonLabs has access to only
> a tiny percentage of all the platforms Python runs on.  This *has* to come
> from the community.

Indeed, so it would be great if any kind of catalogue site could
include the facility for people to upload binaries and packages and
relate them to the original package.

> > One advantage of having such a well defined process to elect the
> > standard  modules is that it will encourage people to improve the
> > standard modules, instead of re-inventing the wheel.
> 
> PEP 2 is indeed important.

Some areas will probably never yield standard modules - the lack of
responses to Andrew Kuchling's Web modules PEP highlighted the
fragmentation and the "more than one way to do something" inherent in
certain areas. However, more accessible information about available
modules and frameworks would prevent the more blatant wheel
reinvention activities; the reason I made a Web modules overview [1]
was to try and inform people of what was already out there and to open
up the debate around Web frameworks beyond the "use Zope" mantra which
predominated at the time, but I doubt that my site is any more obvious
to the disorientated masses than the
not-exactly-obviously-located-nor-up-to-date topic guides on
python.org.

What most of this requires is organisation which, as someone claimed,
is boring to many in comparison to the playful activity of looking at
new or marginalised languages, plundering interesting features and
bringing them home to Python. This isn't to say that language
enhancements aren't useful or necessary, but perhaps it is time to let
the applications dictate the direction of Python, just as (for
example) Unicode support was dictated by (amongst other things) the
need to support XML properly, which in turn was clearly dictated by
real-world applications, rather than the "wouldn't this be cool"
justification which some seem to feel is hiding behind some recent
language innovations.

And perhaps it is time to encourage the most enthusiastic in the
community towards libraries and modules, rather than increasingly
contentious core language improvements. It did occur to me that since
the core language development work is better centrally organised than
work on modules, this could be influential in encouraging so many
suggestions for improvements, but then language tweaking has always
been a favourite pastime for newsgroup contributors over the years.

Personally, whilst I have been an experimenter in terms of programming
languages in the past, these days I very quickly look at the library
or module support available for a given language, usually consigning
the candidate language to the list of "interesting but not that
interesting languages" shortly thereafter. After all, there's real
work to be done and real software to be written, not just neat
demonstrations of interesting concepts.

Paul

[1] http://www.paul.boddie.net/Python/web_modules.html