[Python-ideas] [PEP8] Predicate consistency

Marco Buttu marco.buttu at gmail.com
Fri Feb 6 09:06:29 CET 2015


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 at oa-cagliari.inaf.it



More information about the Python-ideas mailing list