On Tue, 17 Jul 2012 00:19:48 -0500, Andrew Berg wrote:
> To put it in duck-typing terms, why should everything have to quack like
> True or False? Sure, I can see why 1 quacks like True or [] quacks like
> False, but I don't see why say, a Logger or function should quack like
> either.
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as false-like. Since both loggers
and functions are objects, they are true-like unless the default is
overridden.
If you don't like that simple, consistent model for truthiness, feel free
to design your own language with a different model. Or you can use any
one of the dozens of other existing languages which do what you want.
> Should a Thread object be True if it's been started and False
> otherwise?
If you, the Thread class author, want it to be, you can make it so.
> If it truly is about something vs. nothing, why is a NameError (or
> AttributeError) raised when testing with an undefined variable? Being
> undefined quacks like nothing, doesn't it?
Not really. It doesn't quack like anything.
Are you suggesting that if x doesn't exist, you want this behaviour?
>>> del x # make sure x doesn't exist
>>> if x: print('cheese')
... else:
... print('x is falsy')
... print(x)
...
x is falsy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
OH MAN, that would be SO AWESOME, we should like so do it!!!
(I'm being sarcastic, in case it's not obvious.)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
