PEP 285: Adding a bool type

[Mark McEahern]

[Laura Creighton]
> [...]  I am rejecting the existence of booleans in the language
> because it is too hard to teach how to use them properly.

How do you use them properly?

Suppose I want to validate users.  I might write something like this:

	def isValid(user, password):
		if ...:
			return True
		else:
			return False

I can see why it might be better to write:

	def validateUser(user, password):
		# Yes, of course, I'd really hash it.
		try:
			realUser = getUser(user)
		except UserNotFoundError:
			raise AuthenticationError, ...
		realPassword = getRealPassword(realUser)
		if realPassword != password:
			raise AuthenticationError, ...

I don't see how the latter is somehow avoiding the sin of using booleans,
though.  (Of course, I'm sure there's an even better way to write it.)  I
mean, the comparison between realPassword and password--is that not boolean?
Or are you saying I really care here that Python actually allows me to know
whether realPassword is less than or greater than password?

If so, what's wrong with encapsulating that intention in a function?

Using isValid, that returns one of two possible answers, is as clear and
bright as day to me.  If later on I want a function that does something
different, it would most definitely be named something different.  Why on
earth would I want a function named isFoo to return one of more than two
possible values?  (Your answer is probably that you never want a function
named isFoo.  Hmm, I still don't see why.)

Worrying about the fact that I already have something named isValid when I
go to scratch this newfound itch seems to me like worrying that I'm going to
run out of numbers.

That you want a function whose return values are broader than isinstance
doesn't mean there's something wrong with isinstance.

Cheers,

// mark