[Distutils] Access to Python config info

[Fred L. Drake]

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