pep-8 vs. external interfaces?

[Carl Banks]

On Jan 4, 1:47 pm, 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.  Otherwise, it's pep-8".  That'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.


Carl Banks