pep-8 vs. external interfaces?

[Aahz]

In article <27c6b149-3a5f-478d-a6fc-da87a66b9d4c at r36g2000prf.googlegroups.com>,
Carl Banks  <pavlovevidence at gmail.com> wrote:
>On Jan 4, 1:47=A0pm, Roy Smith <r... at panix.com> wrote:
>>
>> Or, I could draw a line in the sand and say, "If it's a protocol
>> primitive, it stays as written. =A0Otherwise, it's pep-8". =A0That's a
>> little uglier because it's not always obvious to the user exactly
>> which names are protocol primitives and which are higher-level
>> operations.
>
>So the question becomes, "Why are you mixing protocol primitives and
>high-level operations in the same namespace?"  Because that's not
>normally a well-advised thing to do.
>
>1. If you answered, "I shouldn't be", you should separate them and use
>camel case for the protocol primitives.
>
>2. If you answered, "I'm including protocol primitive functions
>alongside high-level operations because conceptually they are the
>same, it's just that some functions happen to map directly to the
>underlying protocol", you should follow PEP-8, because by doing that
>you've implicity raised the protocol primitive functions to high-level
>status.
>
>3. If you answered, "Protocol primitives are in the same namespace for
>convenience, but high-level users shouldn't use them", then you should
>use camel case for the protocol primitives but prepend an underscore.
>
>4. If you answered, "I include those functions in the same namespace
>because I am following the example of other language bindings in Perl,
>Java, Ruby, etc.,", then figure out whether it's important to be
>consistent with Perl, Java, Ruby, etc., and if so, do whatever they
>did.  If not, see #1.

This deserves to be recorded on a web page somewhere -- can you stick it
on the wiki?  (I got laid off two weeks ago, so if you're too busy,
would you like me to do it?)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan