[Python-3000] Proposal: No more standard library additions
greg.ewing at canterbury.ac.nz
Mon Oct 23 02:25:33 CEST 2006
Martin v. Löwis wrote:
> If that is so, just ignore the warnings.
Not acceptable, because it means I have to examine
all the warnings every time I compile to check that
another one hasn't appeared that represents a real
> one way to solve the problem is to make the warnings
> go away.
The most straightforward way to solve the problem
is not to ask for these warnings in the first place.
Or at least it would be if I had a decent amount of
control over what warnings get asked for.
> I'm wondering what a make-like system would look
> in this case. Would I write
> $(TARGETDIR)/foo/bar.py: foo/bar.py
> cp foo/bar.py $(TARGETDIR)/foo/bar.py
Don't take "make-like" too literally. All I mean
is something organised around a dependency graph
rather than a list of things to do one after the
The nodes in the graph needn't be individual files.
The whole package-to-be-build would be a node,
which would depend on the nodes representing the
The specification would probably look fairly
similar in some ways to what you currently pass
to the setup function, i.e. a list of .py files that
go into the package. But the internal structure
would be built out of dependency graph nodes
rather than commands and sub-commands.
> If you look at Python's "make install" rule, you
> might agree that "install" is not something that
> plain old make is very good at.
I agree that Make itself doesn't handle install-type
operations very well. I think that's partly because
it's too rigidly fixated on a target being a single
More information about the Python-3000