[Distutils] Access to Python config info
Fred L. Drake
Fred L. Drake, Jr." <email@example.com
Tue, 22 Dec 1998 17:35:31 -0500 (EST)
John Skaller writes:
> Obviously, this does not work. It tests if there is
> a symlinks attribute in os, not what should be tested:
> 1) if there is an attribute symlinks, it works according to spec
> 2) if there is not, then the os doesn't support symlinks
> To perform (1) would require actually creating some symlinks,
> and seeing if they 'worked'. This is what autoconf does;
> it tries to compile various features, and it tests them
> as well (where they're _apparently_ available, and where it
> is possible to do a short test).
> It would be much easier to _document_ that
> the symlinks attribute is present if and only if
> creation of symbolic links is supported with
> semantics XXXX (fill in specification here).
Oh, you want this to be an *operating system* standard. I don't
think PyOS has been released yet.
Seriously, a language should expose interfaces to system services,
not make guarantees as to the conformance of the O/S to some
standard. I think the Open Group is in charge of X/Open conformance
If you want a higher level interface, you need to build it. Once
you've demonstrated generality, you can describe it as a standard,
document it, and try and get others to adopt it. *That's*
standardization. There are good reasons the IETF requires at least
two independent implementations of a specification to make it an
internet standard: that shows that the interface is sufficiently
general and useful that it was worth two organizations supporting the
development work. Until, it's just a specification. Which is the
most we need here.
> with some work done on building these frames,
> but I'm not actually using any of it.
Sounds like it's not really needed.
> You might start by reading the relevant sections
> in the online interscript doco. Then there
> is something concrete to discuss.
As Greg Stein asked: please provide *specific* pointers: which
sections are relevant?
> Consider JPython everywhere. Don't assume CPython.
Good point, especially for those of us that don't normally use it.
Fred L. Drake, Jr. <firstname.lastname@example.org>
Corporation for National Research Initiatives
1895 Preston White Dr. Reston, VA 20191