On 06/02/2015 07:45, Andrew Barnert wrote:
Elsewhere the PEP talks about consistency with related code. If "isnan" is documented to do effectively the same as the C function of the same name it makes sense to use the same name. That's presumably also why "inspect.isgeneratorfunction" doesn't use underscores--they're arguably necessary, but consistency with "isfunction" trumps that.
Your are right we have to keep consistency with other code, but I think we should prefer *horizontal consistency* (I mean with our codebase API) over a *vertical* one.
Also, are you sure it's really "predicate" that's the relevant difference, as opposed to, say, "short word and really short word" (which is really just a special case of "not necessary for readability").
Looking at the core and the standard library, I see we basically do not use underscore in get/set and predicates. This may be a clear general rule, and not "short word" that is not clear at all. How can you explain the following? sys.getswitchinterval() sys.setswitchinterval() asyncio.iscoroutinefunction() and: sys.exc_info() asyncio.wait_for() In these cases you can see we do not use the rule "short words", but almost always the rule: "get/set and predicates should not have underscores". I wrote almost always because sometimes we break that rule: asyncio.get_event_loop() float.is_integer() And my point is that we break it because of a lack in the PEP8. But perphaps I am alone thinking that is ugly to have this kind of inconsistency in predicates and get/set function/method names
You use "dont_write_bytecode" as an example of something that obviously needs the underscores.
I think it is not obvious at all. It is obvious just in the case we have a rule about predicates and get/set, othewise I do not understand how come it is possible that sys.dont_write_bytecode() should obviously have underscores but sys.setswitchinterval() should not.
And beyond your own example, "is_greater_than_one" or "can_fit_on_filesystem" seem like they need underscores, while "dotwice" seems fine without.
I said the opposite: is_greather_then_one() should have unserscores, and as the PEP8 says, the naming rule is the same for functions and methods. In the standard library we do not have any can_* function or method, but if in the future we will have one, then yes, I propose it should be consistent with the "predicate rule" (no underscores). -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbuttu@oa-cagliari.inaf.it