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. Should a Thread object be True if it's been started and False
otherwise?
True and False are red herrings. It is more appropriate to think that
True quacks like something and False like nothing than the other way 'round.
Maybe some examples from my own code will help:
DbfTable --> True if any records in table, False otherwise
DbfIndex --> True if any records in index, False otherwise
DbfList --> True if any records in list, False otherwise
DbfDate --> True if a date, False otherwise (could be eight spaces
instead of a real date)
DbfDateTime --> True if a datetime, False otherwise
DbfRecord --> True always
DbfRecordTemplate --> True always
DbfRecordVaporware --> False always
While I could have DbfRecord be False if, for example, it had no data
stored in it, I have no use case for that scenario so haven't bothered.
Also, at this point I am using the distinction of True/False with
regards to records to determine if I have a real record (True means a
record/template I can read/write, False means I don't).
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?
It's about /representing/ something vs. nothing. An undefined name isn't
representing anything (except a bug, of course ;).
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
