[Tutor] beginning to code

ROGER GRAYDON CHRISTMAN dvl at psu.edu
Wed Sep 13 12:18:06 EDT 2017


I have not yet mastered how to respond to a particular note in a threadwith the
mailer that I use, so this is not in response to anyone in particular,but just
to some of the sentiments as a whole.
>  if x:>      # do something
Completely out of context, I would dislike it just because it is far too
vague.Is it testing for zero?  for an empty list?  or for some object's
completelyarbitrary definition of truthiness?
x.._bool__() seems to me to be just as efficient, but we don't like calling
dunders.bool(x) should mean the same thing, perhaps with an extra function
invocationto look for the dunder.
But even so, nothing here sheds light on what that Boolean outcome means.
I would agree that testing any of those for '== True' or the like is
pointlessredundancy, which may or may not be slower, depending on optimization
issues.
------
but in context is another thing entirely.
was x assigned to recently?   is the type of x obvious so its truthiness is
also obvious?Then fine -- if it is clear that x is a list, I'm happy to use
this to test for an empty list.But if x is some other creation, like a user
defined type, I would really prefer to seesomething analogous to:
if not x.is_empty()     or    x.exists()     or    x.has_brain()
And most definitely if x is assigned outside my control, I would definitely
wantsome way to test or verify x's type before I start using it, lest my
randomnumber generator with its
(A + B * C) % D
finds itself concatenating strings and formatting data.
Roger Christman



More information about the Python-list mailing list