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