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 && [EMAIL PROTECTED] && 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
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to