Re: [Distutils] Access to Python config info

[example has_symlinks() elided]
But this can be written on top of feature tests. Why not?
because it cannot be done.
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). Then I could rely on the above code. To perform (2) is hard, but might involve using shell scripts. (Assuming you have a reliable way of launching them :-)
Have you created a list of the system aspects that this is desirable for? Is the list *finite*?
No. I just keep running into problems. And, obviously, it is desirable to have a finite list: tradeoffs are necessary.
It may well be, but there will be a lot of disagreement over what it should be.
yes. But there is nothing new here :-)
For now, let's call this the "features" module. Are you ready to propose an API?
No. But I will work on it with others. I do have some architecture developed in interscript for this: several frames for different categories of features: * platform * user * site with some work done on building these frames, but I'm not actually using any of it. You might start by reading the relevant sections in the online interscript doco. Then there is something concrete to discuss. It's quite clear that the separate 'compilers' stuff ought be part of this(but isn't, in interscript 1.0a7-9).
Yes, I agree. One way to help that process is to try to _use_ an actual implementation. I have an implementation, but I'm not using it. I could use help structuring it; doing so requires the combined knowledge of many people with experience on many different platforms. I, by myself, do not have wide enough experience. I do have one comment to guide your thoughts. Consider JPython everywhere. Don't assume CPython. ------------------------------------------------------- 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 wrote:
No. If it is there, then it should work. If it doesn't, then ask Guido what he'd like to do. His answer will be one of: 1) it should be removed for that platform 2) it will stay; test sys.platform to determine whether it will work. There is no reason for anything to code defensively against the standard distribution library. There is no need to second-guess all of its modules and functions. [trimming the rest of this email note] Can you send around a URL to the interscript online doc? And when you refer to it, could you please cite a more specific reference? Call it a character flaw, but I'm not going to just blindly go read a bunch of doc. A concrete reference helps (me, at least) provide some focus/structure to why I'm there reading the thing in the first place. Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein writes:
This one.
2) it will stay; test sys.platform to determine whether it will work.
Never this. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191

John Skaller writes:
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 these days. 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.
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 -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191

John Skaller wrote:
No. If it is there, then it should work. If it doesn't, then ask Guido what he'd like to do. His answer will be one of: 1) it should be removed for that platform 2) it will stay; test sys.platform to determine whether it will work. There is no reason for anything to code defensively against the standard distribution library. There is no need to second-guess all of its modules and functions. [trimming the rest of this email note] Can you send around a URL to the interscript online doc? And when you refer to it, could you please cite a more specific reference? Call it a character flaw, but I'm not going to just blindly go read a bunch of doc. A concrete reference helps (me, at least) provide some focus/structure to why I'm there reading the thing in the first place. Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein writes:
This one.
2) it will stay; test sys.platform to determine whether it will work.
Never this. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191

John Skaller writes:
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 these days. 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.
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 -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
participants (3)
-
Fred L. Drake
-
Greg Stein
-
John Skaller