Boolean tests [was Re: Attack a sacred Python Cow]

Erik Max Francis max at alcyone.com
Tue Jul 29 22:23:10 EDT 2008


Carl Banks wrote:

> Bzzt.  "if len(x)!=0" is a simple explicit that would work for this
> class and all built-in containers. (Or should--Steven D'Aprano's
> objections notwithstanding, any reasonable container type should
> support this invariant.  From a language design standpoint, an "empty"
> builtin could have been created to simplify this even more, but since
> there isn't one len(x)!=0 will have to do.)

That you choose not to test for non-emptiness doesn't change the fact 
that it's already a builtin part of the language that is supported by 
all fundamental types and is overridable by anyone writing a custom 
type.  Use it or don't use it, but it's an example of precisely what you 
were asking for that is both practical and already in widespread use.

> Now, you guys keep whining "But what if you don't know what kind of
> object you're expecting?!!"  It's a fair question, and my belief is
> that, in practice, this almost never happens.  Duck typing happens
> between numeric types often, and between container types often, but
> almost never between both numeric and container types.  Their usages
> are simply too different.

What should a custom type return as its length to pass your 
non-emptiness test if it's a custom sequence class that is an infinite 
generator?  It's non-empty, but doesn't have a length.  You test for 
non-emptiness by Boolean comparison, not by testing its length.

> So I present another question to you: Give me an useful, non-trivial,
> example of some code that where x could be either a numeric or
> container type.  That would be the first step to finding a
> counterexample.  (The next step would be to show that it's useful to
> use "if x" in such a context.)

Well, asked and answered, but it apparently wasn't good enough, so I 
doubt anyone's going to enjoy playing your game much further.  You're 
asking for an example of something that demonstrates a use case that's 
_already used by all the builtin types_, so eh, have fun drawing 
imaginary lines in the sand.

> Once again, I'm invoking the contraint against simply using x in a
> boolean context, or passing x to a function expecting a boolean
> doesn't count, since in those cases x can be set to the result of the
> explicit test.

Next answer you're just add another constraint, so I suspect the only 
one enjoying this word game is you.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
   Love is the selfishness of two persons.
    -- Antoine de la Salle



More information about the Python-list mailing list