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