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

[Greg Ewing]

Martin v. Löwis wrote:
> One would have to study it in more detail. What
> is the processing need of a Pyrex file?

Pretty simple -- just pass the .pyx file through
the Pyrex compiler, then do whatever you would
normally do to the resulting .c file to turn it
into an extension module.

A refinement would be to do this only if the
.pyx or any .pyd it uses is newer than the last
generated .c file.

> I would
> expect there is some activity on building, and
> some activity on installing

Nope, it installs just like any other extension
once it's built.

> Right, and the appropriate mechanism here is to
> create a sub-command of build:

Not sure exactly what you mean by a "sub-command".
If you mean a subclass of the class that implements
the "build" command, that's far too heavyweight.
I want to deal just with the .pyx->.c transformation,
and not have to worry that I might mess up something
else that the build class does.

Also, what happens if I want to use my extended
build class together with someone else's extended
build class? Do I have to merge them using multiple
inheritance? Without knowing a *lot* about their
internals, I'd be very nervous doing that lest they
interact in unforeseen ways.

> Right; changing that isn't easy (you could change
> the installed Makefile, and have the change in
> effect for all C extensions).

That's actually what I ended up doing in my own
Python installation. But it doesn't help anyone
else.

> However, I would argue
> that it is really bad that Pyrex generates code
> that compiles with warnings. It shouldn't do that.

It *doesn't* generate any warnings using the
normal, default C compiler settings -- only the
extremely paranoid ones that the Python installation
defaults to. It would take what I regard as an
unreasonable amount of work on the part of Pyrex to
change that.

But that's a different rant. My point is that
I failed to find a workaround, even by hacking.
"Use the source, Luke" doesn't work if the source
is so convoluted that ordinary mortals can't
understand it.

> Well, can you design a mechanism that would allow to
> solve your problem with frameworks?

If I were dealing with a Makefile, and there
weren't a macro to override that would have the
desired effect, I could replace the whole rule
for linking C files with one of my own that
did whatever I wanted.

So if I were designing an architecture for this,
I would base it on the way Make goes about things.
That's something people are already familiar with,
so they would have some idea how to approach
extending and modifying it.

Note that, again, the point isn't really about
-F options, but that there are too few hooks
exposed for modifying things. Maybe those hooks
exist somewhere, but it seems you have to dig
very deep and understand a lot more than you
should have to in order to find and use them.

 > How would it operate on systems other than
 > the Mac?

It wouldn't have to, because I'm only talking
about tweaking someone's setup.py file so that
it works on my system.

A long-term solution to the framework problem
would be to build knowledge of frameworks into
the standard rules for compiling things on a
Mac. If the rules were isolated from each other
in a more Make-like way, this would be easier
as well.

> See, and I believe this isn't the case for distutils.

Then we seem to have a difference of opinion on
what the basic architecture should be like. I
think it should be more like Make, and I don't
see a way of getting there from here incrementally.

--
Greg