On Thu, 2 Dec 1999, Greg Stein wrote:
On Thu, 2 Dec 1999, Michael Hudson wrote:
... class Acceptor: def __and__(self,rhs): return AndingAcceptor(self,rhs) def __or__(self,rhs): return OringAcceptor(self,rhs) def __neg__(self): return NotAcceptor(self)
Sorry... but this is just silly. This is taking a simple problem of file selection and throwing a mess of procedural code at the thing. How is this *any* better than a simple list of files or file patterns?
The distutils package must be *very* simple to gain acceptance. Requiring people to write code, understand how to subclass CCompiler, or provide a bazillion params to a setup() function is just not going to help.
Perhaps I should have been more clear: I am in absolute agreement that it must be possible to be able to use distutils very simply. However it is my contention that it should also be extremely flexible, becuase if you want to do something a little bit unusual you should be able to do it without abandoning the advantages of distutils. I do not believe these aims are incompatible. What should be supplied is an easy to use system with sensible defaults such that the complexity of specificying which files to ship is commensurate with the complexity of your requirements. "ship *.py and foomodule.c" is a simple specification and there should be a simple way of saying it. If your specification is just a little more complex, then there should be a clear and coherent way of extending your setup.py file to accomodate it; if your specification is so fiendishly complex then you are going to need to write code to express it, then you should be able to that too.
This applies to far more than just distribution systems of course, and is my main greivance with just about every bit of software that I have ever used... this is part of what the guile project is about. From http://www.gnu.org/software/guile:
When you decide you need a scripting language or a configuration file, the first impulse is, ``I'll just do something clean and simple.'' This is the right impulse: a full programming language with conditionals,loops, local scopes, and procedures is just a distraction from your project. But simple languages never stay simple. For example, early releases of PHP, a language for generating web pages on the fly, touted its minute memory footprint and simplicitly. Well, the latest release of PHP has its own object system. Compare Tcl circa 1988 with the modern beast. Same story with Perl. The point here is not to criticize these (very successful) tools, but rather to show that simplicity in a scripting language doesn't last long. The real challenge is to age well.
Whatever you may think of guile, they have a point.
Oops, got a bit carried away there.
The developer ought to be able to say "ship *.py and foomodule.c". distutils would package that into a target directory and see that foomodule.c is compiled to a module on the target system. Done.
Yes. However that should not (in my opinion) be *all* that can be said. A case could be made that there should be a limit on how complex your specification should be, but I don't buy it. Turing complete is enough for me ;-).
Grain of salt time: until I step up and provide code to make distutils as simple as I hope it would be, my comments should be viewed as "peanut gallery" comments.
Same for me too, of course. But this is Python, so we'll be able to implement our ideas in about fifteen seconds, right <wink>?
Michael