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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
