Re: [Distutils] Access to Python config info
At 14:22 21/12/98 -0500, Fred L. Drake wrote:
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.
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. [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???
But this can be written on top of feature tests. Why not?
Sigh. Because there is no reliable way to test features. FOR EXAMPLE: consider the module 'commands'. How do I know if it works?? I do not see how to test it .. WITHOUT assuming it works. In fact, you can see by examining the code it will NOT work on NT. So interscript has it's own module called 'commands' that works on both posix and NT. I can't 'test' if it works, because it is one of the modules I need to test if tools such as patch and diff work. I have to rely on it working. ------------------------------------------------------- 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:
... 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/
John Skaller writes:
I don't think that is really my point. I'm interested in a STANDARD, not just good documentation.
Until Guido says otherwise, the standard documentation *is* the standard. If it isn't clear, well, <DocumentorsHat> I'm always open to specific suggestions and patches </DocumentorsHat>. I'm not being defensive here, I don't think, but the documentation has always been the standard for Python. Where there are holes, the implementation is the standard.
language specification. I want to be shown wrong about the library (when I am), the same way.
Was the above paragraph sufficient? ;-)
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?
No. The presence of the function is sufficient. If the underlying system calls don't work as described (where that's an issue), there is either a bug in the documentation or a bug in the syscall implementation. -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