[Python-3000] Proposal: No more standard library additions

[Greg Ewing]

Martin v. Löwis wrote:

> It's only a terminology issue, but I think most people would assume
> a different definition for "extensible". I'd call a system extensible
> if it supports being extended, period.

What matters is how easily and in what ways it can be
extended. My experiences with attempting to extend
distutils or modify its behaviour have not been happy.

1. Pyrex: The distutils extension for compiling Pyrex
modules (which was contributed, not written by me)
seems to work by abusing an existing mechanism for
dealing with swig files. That it was necessary to do
this rather than just adding something new is not a
good sign.

Extension of distutils seems to revolve around the
idea of adding new commands. But I don't want to add
a command, I want to add a new kind of *object* (a
.pyx file) and specify how to transform it into
another kind of object (a .c file) which distutils
already knows how to deal with.

2. Warnings: Distutils insists on compiling C code
with a ridiculously high warning level. For code
generated by Pyrex this is counterproductive, so
I tried to figure out how I could get it to invoke
the C compiler with a different set of options. I
got hopelessly lost trying to follow the code and
gave up.

3. Frameworks: On MacOSX it's often necessary to
link to something that's installed as a framework
instead of a library. Putting -F options in the
extra_link_args doesn't always work because
sometimes they need to be at the beginning. I
haven't found a way to make that happen.

A well-designed extension mechanism would provide
fairly obvious ways of going about all these things.

 > If certain functionality is
> missing in distutils (e.g. means for more transparent extension), then
> distutils should be enhanced to provide this functionality.

Unless the basic structure is so far from what's
needed that it can't be reasonably fixed.

--
Greg