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

[Greg Ewing]

Martin v. Löwis wrote:

> Given that it is *generated* code, I find that very
> reasonable. Just fix the generator once, and the
> warnings will go away.

I don't accept that the code generator needs to be
"fixed", because I don't regard it as broken. The
code it generates is perfectly correct. Its only
crime is not conforming to some C compiler writer's
notion of what spotlessly tidy C code should look
like. That's completely irrelevant for Pyrex-
generated code, since humans aren't required to
ever look at it.

I'm using the C compiler as an assembler. I don't
expect my assembler to make moral judgements about
my code. I expect it to do what I tell it and not
talk back.

> 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.

I'm not sure what your point is here. I don't see
why this can't be done under a Make-like system.
The user just needs a way to say "My package depends
on these .py files". The system can still be left to
figure out where they need to go and whether they need
updating.

If you're saying the user needs the ability to
explicitly invoke just that part of the process on
its own, that could be arranged, similarly to the
way you can tell Make to build a specific target.

I don't see why it's all that useful, though. If
the only thing that's changed is your .py files,
running the whole process will still only update
the .py files, due to the dependency tracking.
The only time you really need something like that
is when you *don't* have full dependency tracking.

--
Greg