On Jan 4, 1:47 pm, Roy Smith <r...@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 -- http://mail.python.org/mailman/listinfo/python-list
