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