text: On 03 February 2000, Greg Stein said: > I just had a reasonably evil thought. Looking at the above code, I > thought, "man. look at all those parameters. gets kind of ugly. it would > be nice to not have to pass all those, but just define them at the top > level." Of course, that's when the anti-Pythonic demon possessed me, and I > figured that we could do something like the following (untested) code: [...evil code skipped...] > Now that is fun! :-) > > The only caveat is that any arguments passed to setup() must be keyword > arguments -- it does not define any positional arguments (unlike the > current setup function). Of course, this could be its "specification" > and/or an extension of the above code could fix that. <sarcasm degree="heavy"> Now Greg, I know you recently moved to California, but I don't know where. From reading that code, I'd have to guess you either live in Mountain View, just down the street from a certain Mr. Wall; or you have taken up residence in a low-rent district of San Francisco, and now spend your time smoking crack in between "joke" posts to various Python mailing lists. </sarcasm> <disclaimer tone="confessional"> In a past life, I wrote Perl code that did something rather like what Greg's suggesting. It wasn't quite so evil, though, since Perl has a clearly understood "main" namespace in which "global global" variables (as opposed to mere module globals) can be found. It was handy, but I don't think I'm proud of it... </disclaimer> But seriously folks... I don't really care for the deeply nested data structures you have to construct in order to specify a real-world set of extension modules, either. And I've been toying with some possible "solutions" to the "I need to set compiler flags for individual source files" problem that will only make things worse. Now, you can always make things look nicer with some temp. variable assignments just before the setup() call, eg. ext1 = ('ext1', { ... hairy build info dict ... }) ext2 = ('ext2', { ... another hairy build info dict ... }) setup (... ext_modules = [ext1, ext2] ) But that really only papers over the problem. The thing that keeps hitting me on the head is "What are these deeply nested data structure for?". Well, they describe a project: in this case, a set of Python extension modules. So perhaps the answer is a simple declarative "project description language". Meaning that people will have to write (simple declarative) "project description files" along with their setup scripts. Is this sounding to much like make-land for some people? Or do you think it's just the ticket? Greg