New PEP: Quality Guidelines For Standard Modules

[Carlos Ribeiro]

Now it's a little over midnight, a bad time to give a meaningful reply 
after a busy Sunday :-) You raised several interesting points. I believe 
that some problems are caused by my limited knowledge of english. Sometimes 
I'm not able to make myself clear. I'll try to reply only one of your 
comments; I'll leave the rest of them for tomorrow.

At 10:50 02/07/01 +0800, Malcolm Tredinnick wrote:
>The OS-LIMITED concept was a bit confusing to me the first couple of
>times I read this. Basically, you are saying "write portable code", as
>far as I can tell. If there were other obstacles, wouldn't that make the
>module OS-DEPENDENT? If I'm missing something here, perhaps you can give
>an example of something that is portable code, but OS-LIMITED and not
>OS-DEPENDENT.

Let me try to explain what I meant: some modules are not as portable as 
they should. There is nothing inherently non portable on the module code, 
but the author may have used (maybe inadvertently) some non portable 
feature of some particular platform. This is the what I meant as 
OS-LIMITED. It was my way to define modules that deserve to be "fixed". By 
removing unneeded dependency these modules may become portable, and so 
OS-INDEPENDENT.

Many modules that are available on the net suffer from this problem. Let us 
talk about something simple: some advanced data structure, for example a 
tree. Some implementations available on the net compile only for some 
particular platforms, sometimes because the author used particular features 
of that platform's compiler. In such case, it should be relatively easy to 
remove the dependency in order to make the code OS-INDEPENDENT, as by my 
definition.

As for the rest of your comments, they were all very helpful. I'll try to 
think on them a little bit harder Monday morning after a good sleep 
<wink-and-snore>


Carlos Ribeiro