OK, we seem to have a better degree of consensus on this than on that version number thing. Good -- hopefully we won't scare anyone off with an extended argument. On the superficial front, Marc-Andre hasn't convinced me that sysconfig is a better name than sys.config. (On the other hand, I never said whether I thought it should be a sub-module of sys, or a [potentially ambiguous] module under a package called 'sys'.) My rationale for calling it sys.config is that sys is "Python system stuff"; sys.config would basically be more of the same, but probably a *lot* more -- so I don't think it should clutter up the well-known, well-understood 'sys' module. One other possible name is, of course, 'config', but then the Perl guys might sue us for copyright infringement. >joke!< 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? [Marc-Andre again]
But the install dirs are changeable during configure... we might need some help from Guido here, e.g. the sys module could include the information: sys.configdir, sys.incldir and sys.libdir.
Now you're cluttering 'sys' up with stuff in the yet-to-be-named config module. These directories should just be accessible variables in sys.config, eg. sys.config.install_bindir sys.config.install_scriptdir sys.config.install_libdir etc. Greg Stein pointed out:
Actually, at the discussion, we planned on compiling them right into the interpreter. That would prevent version skews between a compiled Python and the libraries.
However, now that I'm thinking about it... screw that. If "import sysconfig" picks up the wrong version, then you have plenty of other issues to deal with. I'd much rather see a .py file that a bunch of stuff compiled into the interpreter.
I'm torn on this one. Building into Python prevents version skew, keeping it separate means it's easily readable without writing code. Both are compelling arguments. Greg has given one voice in favour of a separate .py file... anyone else? [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?) Finally, John Skaller respond to my sketch of what should be in the config module:
This is too Unixy.
Absolutely true. I never claimed to be anything but a Unix bigot. Two rebuttals though: * if platform X supports running the compiler from a command line or a script, surely that compiler can take some arguments... and surely some of those arguments will deal with optimization/debugging, some will deal with preprocessor settings, and some are just plain miscellaneous * splitting the flags up into all those categories can be useful, but it could be that I'm confusing the Python build process with the extension module build process. Perhaps the way to build an extension should be carved in stone when Python itself is built, and extension builders shouldn't be allowed to muck with it. If so, then John is absolutely right about just calling a function to invoke the compiler for such-and-such a situation. Gee, I guess that second one wasn't much of a rebuttal. So much for my combative spirit. ;-)
An excellent sketch though. Why? because it is concrete enough to be argued about!
Thank you! that was the whole idea; I hate abstract arguments (the only courses I came close to flunking in university were philosophy and psychology...). And I have a nasty tendency to attack anyone who brings up airy-fairy concepts with *something* concrete to explain his ideas. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward writes:
On the superficial front, Marc-Andre hasn't convinced me that sysconfig is a better name than sys.config. (On the other hand, I never said whether I thought it should be a sub-module of sys, or a [potentially ambiguous] module under a package called 'sys'.) My rationale for
A lot of Python programs import sys, more than will need sys.config, so there seems no reason to force all those programs to import another .py file that they're aren't going to actually use. On the other hand, if the config information winds up stored in the Python binary, then sys.config will just add a few dictionary entries, so it might as well be there. Alternatively, sys.config could be some sort of magic object that only imports the .py if it's actually accessed, but that's an ugly hack. I'd sum it up as: if it goes in the Python binary, sys.config is OK. If it goes in an external .py file, sys.config is not OK, and I'd vote for sysconfig or some new package.
I'm torn on this one. Building into Python prevents version skew, keeping it separate means it's easily readable without writing code. Both are compelling arguments. Greg has given one voice in favour of a separate .py file... anyone else?
Go for the .py file, IMHO. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ The age of chivalry is gone. That of sophisters, economists and calculators has succeeded: and the glory of Europe is extinguished for ever. -- Edmund Burke, _Reflections on The Revolution in France_
Greg Ward wrote:
On the superficial front, Marc-Andre hasn't convinced me that sysconfig is a better name than sys.config. (On the other hand, I never said whether I thought it should be a sub-module of sys, or a [potentially ambiguous] module under a package called 'sys'.)
Gee, naming issues again... anything with a dot in it reminds me of packages and thus should act like one (submodules are really not a good idea: they contain code that is executed but not necessarily needed by the one who imports the main module). Yet, the sys module is written in C and all the distutils stuff should, IMHO, be done in Python. So the reasons I renamed it from sys.config to sysconfig were simply: · don't make it look like a package when it is not · don't have 'import sys' fill unneeded dictionaries · just naming it 'config' would probably cause name clashes Alternative name: 'pyconfig'
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 wouldn't consider this grotesque hackery. The idea I had was to have the sysconfig module initialize itself at import time (rather than install time). Since it is not often needed this should be a feasable approach. Most of all it works without any changes to the distribution as it is, except maybe...
But the install dirs are changeable during configure... we might need some help from Guido here, e.g. the sys module could include the information: sys.configdir, sys.incldir and sys.libdir.
Now you're cluttering 'sys' up with stuff in the yet-to-be-named config module.
These directories should just be accessible variables in sys.config, eg.
sys.config.install_bindir sys.config.install_scriptdir sys.config.install_libdir
They are... once the module is initialized. But for it to find the necessary templates (Setup, config.h and Makefile) it needs some path information first. Looking at the current Makefile.pre.in though, it seems that this doesn't directly support non-standard install directories either. The parsed information could then be stored in a _sysconfig module which subsequent invocations then use which is close to what Greg proposed except that the first run is not necessarily done by the installation Makefile.
Greg Stein pointed out:
Actually, at the discussion, we planned on compiling them right into the interpreter. That would prevent version skews between a compiled Python and the libraries.
However, now that I'm thinking about it... screw that. If "import sysconfig" picks up the wrong version, then you have plenty of other issues to deal with. I'd much rather see a .py file that a bunch of stuff compiled into the interpreter.
I'm torn on this one. Building into Python prevents version skew, keeping it separate means it's easily readable without writing code. Both are compelling arguments. Greg has given one voice in favour of a separate .py file... anyone else?
The current system has the same problems: Makefile.pre.in looks in the install dirs at boot time. If it finds wrong information then the resulting Makefile will use bogus data. Some people have reported effects of this: strange core dumps and unresolved symbols, even bus errors. Most of them had the install dirs mounted via NFS containing data for other machines than the one they built the extensions on.
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?)
I think the three files pretty much cover all information that is available to Python at compile time (except maybe the os.environ at compile time). -- Marc-Andre Lemburg Y2000: 380 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : ---------------------------------------------------------
M.-A. Lemburg wrote:
... Greg Ward wrote:
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 wouldn't consider this grotesque hackery. The idea I had was to have the sysconfig module initialize itself at import time (rather than install time). Since it is not often needed this should be a feasable approach. Most of all it works without any changes to the distribution as it is, except maybe...
I don't see much of a rationale for *not* doing this at install time. The file is a bunch of constants that are easily determined when you build/install Python. There is a caveat for trying to get it to function with 1.5.2, but I don't believe that changes the long-term interface, which I maintain are simple names/values.
Greg Ward wrote:
These directories should just be accessible variables in sys.config, eg.
sys.config.install_bindir sys.config.install_scriptdir sys.config.install_libdir
They are... once the module is initialized. But for it to find the necessary templates (Setup, config.h and Makefile) it needs some path information first. Looking at the current Makefile.pre.in though, it seems that this doesn't directly support non-standard install directories either.
The parsed information could then be stored in a _sysconfig module which subsequent invocations then use which is close to what Greg proposed except that the first run is not necessarily done by the installation Makefile.
It *should* be done by the installation Makefile. I would hope that we obsolete the third-party use of Setup/config.h/Makefile.pre.in. Those are even close to the convenience that we can establish. So, I'd maintain that we don't need to find those three files, so there isn't a bootstrap issue here. Note that these files are always installed at $(exec_prefix)/lib/python$(version)/config/ (as far as I can tell, that's fixed). Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein writes:
I don't see much of a rationale for *not* doing this at install time. The file is a bunch of constants that are easily determined when you build/install Python.
Yes. It can include code to regenerate the "right stuff" when run as a script as well. Running it as a script can be done at the end of installation.
There is a caveat for trying to get it to function with 1.5.2, but I don't believe that changes the long-term interface, which I maintain are simple names/values.
What's the caveat?
Note that these files are always installed at $(exec_prefix)/lib/python$(version)/config/ (as far as I can tell, that's fixed).
I think you're right. I've attached a sysconfig.py that works on Unix. Someone familiar with other platforms will need to make it work there as well by adding additional _init_<name>() functions; <name> should be os.name. When run as a script, it rewrites itself with the discovered information. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 """Prototype sysconfig module that loads information when run as a script, but only defines constants when imported. This should be run as a script as one of the last steps of the Python installation process. """ # START DATA # END DATA def _init_posix(): import os import re import sys g = globals() version = sys.version[:3] config_dir = os.path.join( sys.exec_prefix, "lib", "python" + version, "config") # load the installed config.h: define_rx = re.compile("#define ([A-Z][A-Z0-9_]+) (.*)\n") undef_rx = re.compile("/[*] #undef ([A-Z][A-Z0-9_]+) [*]/\n") fp = open(os.path.join(config_dir, "config.h")) while 1: line = fp.readline() if not line: break m = define_rx.match(line) if m: n, v = m.group(1, 2) if v == "1": g[n] = 1 else: g[n] = v else: m = undef_rx.match(line) if m: g[m.group(1)] = 0 # load the installed Makefile.pre.in: variable_rx = re.compile("([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*)\n") done = {} notdone = {} fp = open(os.path.join(config_dir, "Makefile")) while 1: line = fp.readline() if not line: break m = variable_rx.match(line) if m: n, v = m.group(1, 2) if "$" in v: notdone[n] = v else: done[n] = v # do variable interpolation here findvar1_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*).") findvar2_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*)}") while notdone: for name in notdone.keys(): value = notdone[name] m = findvar1_rx.search(value) if not m: m = findvar2_rx.search(value) if m: n = m.group(1) if done.has_key(n): after = value[m.end():] value = value[:m.start()] + done[n] + after if "$" in after: notdone[name] = value else: done[name] = value del notdone[name] elif notdone.has_key(n): # get it on a subsequent round pass else: done[n] = "" after = value[m.end():] value = value[:m.start()] + after if "$" in after: notdone[name] = value else: done[name] = value del notdone[name] else: del notdone[name] # save the results in the global dictionary g.update(done) # save the results in the source file filename = os.path.splitext(sys.argv[0])[0] + ".py" lines = open(filename).readlines() start = lines.index("# START DATA\n") end = lines.index("# END DATA\n") newdata = [] items = g.items() items.sort() for name, value in items: if name[0] != "_": newdata.append("%s = %s\n" % (name, `value`)) lines[start+1:end] = newdata open(filename, "w").writelines(lines) if __name__ == "__main__": import os exec "_init_%s()" % os.name del _init_posix
Quoth Fred L. Drake, on 17 December 1998:
I've attached a sysconfig.py that works on Unix. Someone familiar with other platforms will need to make it work there as well by adding additional _init_<name>() functions; <name> should be os.name. When run as a script, it rewrites itself with the discovered information.
Cool! I have two itty-bitty teeny-tiny nits to pick:
"""Prototype sysconfig module that loads information when run as a script, but only defines constants when imported.
This should be run as a script as one of the last steps of the Python installation process. """
*This* version should run as one of the last steps of the distutils installation process, ie. this is the hack that'll work with Python 1.5.2. The nice version that will be bundled with Python 1.6 (I'm hoping!) might just be this again, or it might have more direct knowledge of Python's configure-time information. But it should run as part of Python's build process, so it won't go looking in sys.exec_prefix + lib + python + ... -- it'll just find stuff in the current (Python build) directory. But for the first version of distutils, I think this is what we need.
# do variable interpolation here findvar1_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*).") findvar2_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*)}")
Ummm... is this right? Shouldn't the first regex be for $(...) and the second for ${...}? If that's what you were thinking, this'll still work (because of the .'s where there should be \( and \)), but it's a bit inexact. (Feel free to slap me with a wet noodle if I'm missing something obvious here.) Well, Fred, you've set the ball rolling... I guess coding and design will, as usual, proceed hand-in-hand... ;-) Greg P.S. I would like to suggest one coding standard for the project: every source file should have the name and email address of the person who wrote it, the date it was started, and and RCS/CVS identifier of some kind (I'm partial to $Id$ myself, but $Revision$ is also fine). Any objections? P.P.S. I'll see about getting an anonymous CVS archive set up tonight or tomorrow. -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
... *This* version should run as one of the last steps of the distutils installation process, ie. this is the hack that'll work with Python 1.5.2. The nice version that will be bundled with Python 1.6 (I'm hoping!) might just be this again, or it might have more direct knowledge of Python's configure-time information. But it should run as part of Python's build process, so it won't go looking in sys.exec_prefix + lib + python + ... -- it'll just find stuff in the current (Python build) directory.
But for the first version of distutils, I think this is what we need.
Re: Fred Drake asking about the caveat I mentioned. This is it: in the future, the build process just spits out a bunch of assignments. For 1.5.2, we don't have that luxury, so it gets a bit more complicated. Cheers, -g
... P.S. I would like to suggest one coding standard for the project: every source file should have the name and email address of the person who wrote it, the date it was started, and and RCS/CVS identifier of some kind (I'm partial to $Id$ myself, but $Revision$ is also fine). Any objections?
hehe... boy, you do like things in a particular way, don't you? Now I know where the version number stuff came from :-) For better or worse, I don't think you're going to get the level of compliance that you want here. You'll see :-) hehe.... -- Greg Stein, http://www.lyra.org/
Quoth Greg Stein, on 17 December 1998:
P.S. I would like to suggest one coding standard for the project: every source file should have the name and email address of the person who wrote it, the date it was started, and and RCS/CVS identifier of some kind (I'm partial to $Id$ myself, but $Revision$ is also fine). Any objections?
hehe... boy, you do like things in a particular way, don't you? Now I know where the version number stuff came from :-)
I am anal boy; hear me squeak! Actually, I'm doing all this to convince the Python world that not *all* people named Greg are left-coast long-haired anarchists. ;-)^2 But seriously: is it *really* such a burden to put something like this: # # distutils/version.py # # Implements multiple version numbering conventions for the # Python Module Distribution Utilities. # # written by Greg Ward <gward@cnri.reston.va.us>, 1998/12/17 # # $Id$ # in the top of a source file? I don't think so, and it's especially trivial compared to the time spent to write documentation and a test suite. (Which I'm also a fan of. But I figured insisting on them would just get me laughed off the sig, so I kept the request [name, date, RCS id] pretty small. I honestly didn't think even *you* would howl at that... silly me!) Which reminds me, by writing sysconfig.py Fred has shamed me into writing version.py. Should be available in that yet-to-be-created anonymous CVS archive Real Soon Now. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
... Actually, I'm doing all this to convince the Python world that not *all* people named Greg are left-coast long-haired anarchists. ;-)^2
Feh.
But seriously: is it *really* such a burden to put something like this:
# # distutils/version.py # # Implements multiple version numbering conventions for the # Python Module Distribution Utilities. # # written by Greg Ward <gward@cnri.reston.va.us>, 1998/12/17 # # $Id$ #
in the top of a source file? I don't think so, and it's especially trivial compared to the time spent to write documentation and a test suite. (Which I'm also a fan of. But I figured insisting on them would just get me laughed off the sig, so I kept the request [name, date, RCS id] pretty small. I honestly didn't think even *you* would howl at that... silly me!)
I'm not howling, and I never said it was a burden (so there! :-). In fact, I don't really have much of a problem with it. If I *remembered* to do it, then I'll add them for any code I drop off. However, I'm a realist... I'm laying odds that you won't get everybody to add those headers. Call me a cynic, but you're working against the habits of a bunch of programmers. There is very little on the planet that has the stubborness of a programmer :-)
Which reminds me, by writing sysconfig.py Fred has shamed me into writing version.py. Should be available in that yet-to-be-created anonymous CVS archive Real Soon Now.
Hey, I gave you some code for versions. It worked great for me :-) -g -- Greg Stein, http://www.lyra.org/
Greg Stein writes:
Re: Fred Drake asking about the caveat I mentioned.
This is it: in the future, the build process just spits out a bunch of assignments. For 1.5.2, we don't have that luxury, so it gets a bit more
Greg, 1.5.2 isn't out yet! -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Greg Ward writes:
*This* version should run as one of the last steps of the distutils installation process, ie. this is the hack that'll work with Python
If we can agree that it includes sufficient information, and we can get the other platforms supported, why can't we ask Guido to include it in 1.5.2? That would also allow other projects that have differing views to use the same fundamental information. That way running it is only needed as part of the Python build/install (should be install, esp. for people using things like RPM, where the locations may change after the build).
1.5.2. The nice version that will be bundled with Python 1.6 (I'm hoping!) might just be this again, or it might have more direct knowledge of Python's configure-time information. But it should run as part of Python's build process, so it won't go looking in sys.exec_prefix + lib + python + ... -- it'll just find stuff in the current (Python build) directory.
Stuffing in the build directory isn't useful. Now that you have me thinking about this, it perhaps *is* useful to at least build the paths at import time. The Python distribution is supposed to be relocatable *after installation* for Unix (at least). The interpreter already does a search for the libraries, and sets sys.prefix and sys.exec_prefix accordingly (I think those get set properly... yes, they are). So: the right way to do this is to set most of the paths at import time. This should not be hard.
# do variable interpolation here findvar1_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*).") findvar2_rx = re.compile(r"\$.([A-Za-z][A-Za-z0-9_]*)}")
Ummm... is this right? Shouldn't the first regex be for $(...) and the second for ${...}? If that's what you were thinking, this'll still work
Ouch! Yes. That was a change I forgot I made while debugging something that was entirely a different problem with the code (I was using match() instead of search(), probably because it's usually what I need).
P.S. I would like to suggest one coding standard for the project: every source file should have the name and email address of the person who wrote it, the date it was started, and and RCS/CVS identifier of some
Cool. I typically use __version__ = "$Revision$" for storing revision control information. This corresponds to a recommendation from long ago; I don't recall the source, but it was probably c.l.py. $Id$ could be added in a comment if desired, but I don't know how useful it is since I don't use it. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Greg Ward writes:
*This* version should run as one of the last steps of the distutils installation process, ie. this is the hack that'll work with Python
If we can agree that it includes sufficient information, and we can get the other platforms supported, why can't we ask Guido to include it in 1.5.2? That would also allow other projects that have differing
Because if we later find out that we need a somewhat different interface or functionality, we have a compatibility problem. I see no need to rush - all information is already available in Python 1.5.1, it just takes some parsing. Konrad [now definitely leaving...] -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen writes:
Because if we later find out that we need a somewhat different interface or functionality, we have a compatibility problem. I see no need to rush - all information is already available in
I don't think this is a problem, really. The question about whether it really belongs in the standard distribution at all is more important. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
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/
Quoth Greg Stein, on 16 December 1998:
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).
I agree: sysconfig.py should be a flat list of globals. A brain-dump of Python's configuration info, as it were. This implies that any functions/methods (eg. for invoking the compiler) belong in some distutils module. After all, this is the 'distutils' project; as much code as possible should go in the 'distutils' package. sysconfig should just be a flat braindump.
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!
My list of gripes with Python is pretty small, but I think the main one is that the word "Dictionary" is just too long to type. And when you write as many comments as I do, that matters... ;-) Just another /^P\w+/ hacker... Greg PS. Oops, I just realized that regex also lets Pascal in, and PL1 (of course it should be written "PL/1" [or is it "PL/I"?]), and Prolog... hmmm... back to the drawing board... -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward writes:
I agree: sysconfig.py should be a flat list of globals. A brain-dump of Python's configuration info, as it were.
I don't see any big reason not to keep it in distutils, either, as long as it can be done the way I did the preliminary thing. I think it's even reasonable to just let it do the information discovery each time, which might make it easier to update Python without having to do anything with an existing distutils installation (in case it's not in there).
My list of gripes with Python is pretty small, but I think the main one is that the word "Dictionary" is just too long to type. And when you
That's why many of us spell it "dict". ;-)
PS. Oops, I just realized that regex also lets Pascal in, and PL1 (of course it should be written "PL/1" [or is it "PL/I"?]), and
I think either, depending on which you used. Wasn't one a subset of the other? -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
participants (6)
-
Andrew M. Kuchling -
Fred L. Drake -
Greg Stein -
Greg Ward -
Konrad Hinsen -
M.-A. Lemburg