Re: [Distutils] Access to Python config info
At 08:07 22/12/98 -0500, Greg Ward wrote:
Quoth John Skaller, on 20 December 1998:
I think you are missing the point here: if the configuration doesn't work, the client has NO CHOICE but to edit it. And if it isn't editable, the client has NO CHOICE, full stop. Now, you don't want to leave the client without options, in case something as complex as configuring a compiler fails, do you?
John -- I don't think not being able to edit sysconfig leaves people out in the cold. Fred's current implementation is, in fact, quite non-editable, as it scans Makefile and friends as late as possible (ie. when sysconfig is itself imported).
Let me cut the arguments, and simply phrase a request. This gives us BOTH what we want. :-) EXECUTIVE SUMMARY 1. module parse_configuration, function get_config returns a dictionary of config data parsed from the makefile 2. module sysconfig exhibits attributes corresponding to the result of executing get_config when loaded 3. module build_config, by default, exhibits the attributes corresponding to the result of executing get_config AT BUILD TIME This module may be edited by the client. 4. The tool 'refresh_config.py' can be executed to print the (dynamic) configuration to standard output, and thus be used to generate a configuration module, including the standard one (3). DETAILS. Allow me to assume sysconfig.py, as it stands, is copied to parse_configuration, renamed get_config, and edited slightly to conform to the specified interface. Here is the new implementation of module sysconfig, with the same semantics as the existing one: # distutils.sysconfig from distutils.parse_configuration import get_config globals().update(get_config()) Nifty, eh? :-) Here is 'refresh_config.py': # refresh_config.py from distutils.parse_configuration import get_config for key, value in get_config().items(): print key+'='+repr(value) As you can see, both these auxilliary things are a single line of code. This is packaging. It is possible just by isolating the parser, and not doing anything tricky. :-) I think that invoking the refresh utility in the make process is also a single line change to the makefile! WAFFLY IMHO THEORETICAL COMMENTS: It is best to have stateless entities do the work, and then provide state as required by the architecture. Separating out the functionality is crucial to building multiple architectures: it allows the architectural implementation to be largely independent of the implementation of the functionality. This is the secret of Python methods: they're just plain old stateless functions. Bound methods are just architecture, independent of the functionality encoded in the unbound method. We should emulate this good, orthogonal, design! /WAFFLE Comments? ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia
participants (1)
-
John Skaller