[Python-3000] Proposal: No more standard library additions
"Martin v. Löwis"
martin at v.loewis.de
Mon Oct 16 06:46:20 CEST 2006
Greg Ewing schrieb:
> 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.
One would have to study it in more detail. What
is the processing need of a Pyrex file? I would
expect there is some activity on building, and
some activity on installing (perhaps not so,
as it may install as an extension).
> 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.
Right, and the appropriate mechanism here is to
create a sub-command of build: you are trying to
explain how to *build* the .c file.
> 2. Warnings: Distutils insists on compiling C code
> with a ridiculously high warning level.
Well, it really uses the settings that were determined
when Python itself was compiled. It doesn't know at
all what a compiler warning is and how to turn it on
or off.
> 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.
Right; changing that isn't easy (you could change
the installed Makefile, and have the change in
effect for all C extensions). However, I would argue
that it is really bad that Pyrex generates code
that compiles with warnings. It shouldn't do that.
> 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.
Can't comment here, since I never had this problem myself.
> A well-designed extension mechanism would provide
> fairly obvious ways of going about all these things.
Well, can you design a mechanism that would allow to
solve your problem with frameworks? How would it
look like? How would it operate on systems other than
the Mac?
> Unless the basic structure is so far from what's
> needed that it can't be reasonably fixed.
See, and I believe this isn't the case for distutils.
Regards,
Martin
More information about the Python-3000
mailing list