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

"Martin v. Löwis" martin at v.loewis.de
Wed Oct 18 07:15:25 CEST 2006


Greg Ewing schrieb:
>> If they also created a new sub-command for build,
>> you would have to make your get_sub_command implementation
>> return them both.
> 
> If these sub-commands really are independent,
> why can't I just add one to a list somewhere?
> Then it would be no problem at all for different
> extensions to coexist.

You can, sure. distutils.commands.build.sub_commands.
To do so, you either have to edit the source code of
build.py, or you have to arrange that the addition
is done programmatically somehow when setup.py runs.

> It might be considered reasonable for human-written
> code, but it's not reasonable to expect machine
> generated code to pass such a strict test.

Given that it is *generated* code, I find that very
reasonable. Just fix the generator once, and the
warnings will go away. For hand-written code, any
new piece of code might cause a new warning. For
generated code, because of the systematic way, the
warnings can be removed in the generator, not in the
input (the pyx file). I've been writing generators
that produce C++ for years, and never found it a
problem make it write warning-less, legible code.

> The point about this is that no matter how many
> options you provide to a command, there will always
> be circumstances in which they're not sufficient.
> So there needs to be a clear and understandable
> way to override anything at any stage in the
> process.

Ah, ok. So you'd want a "build command override" for an
extension object. Such a feature could be added to
distutils.

> And if you're doing that, why bother with the
> build steps layer at all? Why not just let the
> user specify the dependency graph directly and
> let it rip?

build_py, for example, *only* copies the source
files into the build tree (with time stamp checking).
The user shouldn't have to specify this, because
a) it is tedious and error-prone to do so for each
   source file, and
b) you can't know in a static way what the target
   directory is, because the platform name goes
   into the target name.

Regards,
Martin


More information about the Python-3000 mailing list