Re: [Distutils] Access to Python config info
At 10:49 16/12/98 -0500, Fred L. Drake wrote:
John Skaller writes:
1) does the OS support symbolic or hard links?
import os hasattr(os, "link") hasattr(os, "symlink")
HOW do you know this works? HOW do you know that the method is not, in fact, present, but doesn't work? WHERE is the standards document that specifies the precise semantics of the 'os' interface?? This technique doesn't seem very reliable. :-(
It may be the proper place for the answer is not in sys.config, but in os. But the os module can compute the answers from sys.config.
For most of this, probably so. Recall also that Guido & others recommend "feature tests" to determine the availability of functionality rather than having a separate flag to indicate availability. There are many ways in which this is more reliable and maintainable,
And some in which it is not reliable :-(
though what we're currently describing as sysconfig remains pertinant. I would expect sysconfig to be used mostly by things like distutils and not by typical programs. Hence, it would be good for os to not import it.
That may be so. However, 'feature tests' are useless for meta-programming. What I mean is: suppose one generated some code. If it had to be different depending on 'features', one could do the feature tests and generated it that way; but this would only work on the current platform. If you were generating code for someone else; then the feature tests would be useless ... unless they were done _by_ the generated code. Which is the autoconfig nightmare all over again. What Guido is recommending is exactly like the old fashioned DOS driver problem: test the video, or printer to see what kind it is, and configure a driver: usually by selecting it from a list a mile long _supplied with every single program_. I don't think this is precisely the way to do it. Dynamical feature tests are fine if they are done ONCE on installation; and present the results in a platform independent way. All modern operating systems have an abstract device driver API, and the _operating system_ installs the appropriate driver once when it is configured. With any luck, the configuration record can be ported, so it is possible to generate code for any configuration, (i.e. on a remote host): the generator _might_ optimise the code my providing some dynamic testing (of the configuration record on the client). Of course, the reliability of this mechanism does depend on establishing standards, and then making the implementation(s) comply. There's no reason the configuration module shouldn't do these dynamical tests _as implementation details_ of the implementation of a standardised API. If they're appropriate. _I_ don't want to do this hackery in code, however. It's too much like a bag of trickery. I'd be happy with a module containing: def has_symlinks(): import os return hasattr(os, "link") with a _specification_ of the function has_symlinks because this would allow me to create an alternate implementation (which could, for example, use a data record to represent the configuration of some remote system). Does this make sense? ------------------------------------------------------- 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
John Skaller writes:
HOW do you know this works? HOW do you know that the method is not, in fact, present, but doesn't work? WHERE is the standards document that specifies the precise semantics of the 'os' interface??
Sounds like I'd better get the documentation for "os" fixed before I release again; it is on my list.
This technique doesn't seem very reliable. :-(
How so? (Given that functions will be provided only when the underlying system defines the corresponding capability.) Your issue with this sounds like fixing the documentation would be sufficient.
That may be so. However, 'feature tests' are useless for meta-programming. What I mean is: suppose one generated some code. If it had to be different depending on 'features',
...
If you were generating code for someone else; then the feature tests would be useless ... unless they were done _by_ the generated code.
These are runtime tests. Generated code that relies on the result should make them as appropriate. Note that the only time they are appropriate *ever* is if you provide alternate functionality (however simple) for platforms that fail the test, or if you want to remove options from view in a user interface for platforms which don't offer the functionality. Any other time the AttributeError exception is appropriate, and can be caught if needed.
Which is the autoconfig nightmare all over again.
What Guido is recommending is exactly like the old fashioned DOS driver problem: test the video, or printer to see what kind it is, and configure a driver: usually by selecting it from a list a mile long _supplied with every single program_.
I don't think this is precisely the way to do it. Dynamical feature tests are fine if they are done ONCE on installation; and present the results in a platform
So once installed, the result ends up being platform specific. In many environments, this is not acceptable. If it is, then your installation-time tests and configuration can be built on top.
_I_ don't want to do this hackery in code, however. It's too much like a bag of trickery. I'd be happy with a module containing:
[example has_symlinks() elided] But this can be written on top of feature tests. Why not? If features are expected to be tested may times, repeatedly, the implementation could be somewhat auto-optomizing by having the functions replace themselves with "fast" versions that just return the result for subsequent queries: def has_symlinks(): global has_symlinks import os if hasattr(os, "symlink"): has_symlinks = true return 1 else: has_symlinks = false return 0 def true(): return 1 def false(): return 0
with a _specification_ of the function has_symlinks
Have you created a list of the system aspects that this is desirable for? Is the list *finite*? It may well be, but there will be a lot of disagreement over what it should be. For now, let's call this the "features" module. Are you ready to propose an API? I'm sure several of us would be willing to read it and carefully consider it (I will, though it may not sound like it;). I think the biggest problem is defining it in a way that provides more information or more convenient access to the information represented. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
participants (2)
-
Fred L. Drake -
John Skaller