John Skaller wrote:
... I don't think that is really my point. I'm interested in a STANDARD, not just good documentation.
Saying what the library does is a useful hint. Like reading the code. It isn't the same as a specification; which _requires_ certain behaviour. The python _language_ document is written more like a specification. If the language doesn't do what the doco says, its a bug in the implementation (or a fault in the doco).
Not an excuse from Guido that it doesn't work on that platform 'because'. I don't want an explanation why something doesn't work, I want an authoritative document that I can cite as evidence of a bug. In other words, relieve myself of the responsibility of fixing it or working around it.
I've been shown that my interpretation of what Python does is wrong, by citation of the language specification. I want to be shown wrong about the library (when I am), the same way.
That specification does not exist, nor does anybody plan to write it. "The code is the spec" applies 100% here. What ships in the standard distribution defines the module. Simple. Done. If you really want it, then I would suggest that you take some time to write it.
[On testing things to see if they work]
This technique doesn't seem very reliable. :-(
How so?
Because it requires testing every single function in the whole system before using anything. Because there is no definitive specification of what might work or not. Do you see?
And just _how_ do I test the functions? Using other functions that are themnselves suspect???
If a function is in the standard distribution, then it should be assumed that it works. That is what Fred is getting at. A "hasattr" says whether it exists or not. If it does, then it should work. And yes, there may be certain caveats to its behavior.
[more about testing and features and commands.py...]
Where is all this going? I have totally lost the point of this discussion. Let's just get back to discussing distutils, can we? Shortcomings of certain modules, how to test the standard distribution, etc, should probably be raised on comp.lang.python. Cheers, -g -- Greg Stein, http://www.lyra.org/