Greg Ward wrote:
... Marc-Andre also said:
Rather than discuss which things to include or not, just put all the information in there you can find by simply parsing Makefile. Note that the parsing mechanism should also allow for fairly decent $(VARIABLE) expansion.
No! At least not in the long term: as Greg Stein pointed out, the config module (whatever it gets called) should just be generated when Python is built. Or were you talking about the near term, where we will need a distutils release that works with Python 1.5.2 and is allowed all manner of grotesque hackery to work around the lack of a config module, such as digging up and parsing Python's config.h, Makefile, and Setup?
I believe the public interface will/should always be a set of names and values. Even if we do a hack in lieu of native Python support, we should just set globals for use by clients. There may be functions in there, too, for compiler invocation and stuff (as John recommends). I'm not clear on whether that needs to be in sysconfig.py or part of the distutils package (forgot the pkg name).
... [Greg S. again]
I'd also recommend ignoring all the dictionary vs instance stuff. Just have a bunch of assignments dropped into a sysconfig.py module. IMO, it would look a lot like FCNTL.py (h2py output files). No need to get fancy with defaults and stuff. Just write the dumb file out.
I (almost) completely agree. If we put *everything* from config.h into the config module, it might be nice to store it separately (eg. in a hash). But the stuff from Makefile and Setup should just be dumped in flat as variables. Are there other sources of information we should be worrying about? (Eg. does config.cache have anything valuable that doesn't wind up in config.h or Makefile?)
All right, you Perl hacker. We'll have none of this here! Python doesn't have "hashes" ... it has dictionaries! Also, it is always possible to view module globals as a dictionary (with vars(sysconfig)), so there isn't a need for another level containing a dictionary. Go home Perl hacker! :-)
...
Cheers, -g -- Greg Stein, http://www.lyra.org/