This pretty much mirrors the compromise taken in C++. However, most C++
users end up regretting the liberal implicit convertibility among the
numeric types. The latest abomination: if you want to make a new type which
can be tested in a context which demands a bool (e.g. "if (x) {...}"), what
you do is make a private dummy nested class type and give the outer type a
conversion to a pointer-to-member-function of the inner type. This allows
the expected boolean tests but prevents the object from being used in
contexts which expect actual numbers**. This ugly hack is, regrettably, "the
right thing to do" in the face of the promiscuous rules for numeric types.
-Dave
**If you're thinking, "we already have a safe way to allow new types to be
tested as booleans in Python", then you're missing the point.
----- Original Message -----
From: "Guido van Rossum" <guido@python.org>
To: "Greg Ewing" <greg@cosc.canterbury.ac.nz>
Cc: <python-dev@python.org>
Sent: Sunday, March 10, 2002 7:38 PM
Subject: Re: [Python-Dev] For review: PEP 285: Adding a bool type
> > But True - 1 won't equal False. Should it?
>
> No. My logic for deciding the type of "x <op> y" (and for "<op> x")
> is based exclusively on the types of x and y. For a given <op>, the
> type of "x <op> y" should be derived from the types of x and y and the
> properties of <op>. The values of x and y don't enter into it (except
> implicitly, insofar as their type limits the possible values). Thus,
> x&y, x|y, and x^y yield a bool when both x and y are bools, because
> they yield bool values whenever the arguments are both bools; but x+y
> is an int, even when both x and y are bools and the outcome is 0 or 1
> (representable as a bool): this is because there's also a case
> (True+True) where the outcome (2) is not representable as a bool.
>
> The only exception is +x: this returns an int result for a bool
> argument. That's a matter of taste -- the unary + screams "number" to
> me. I could be convinced that it should return x unchanged. But in
> any case the type of the result still only depends on the *type* of
> the argument.
>
> This is a very general rule that I like a lot: that the type of a
> result should only depend on the type of the arguments, not on their
> values. I expect that this rule will make reasoning about programs
> (as in PsyCo or PyChecker) easier to do.
>
> I recently caved in and allowed an exception: 2**2 returns an int, but
> 2**-2 returns a float. This was a case of "practicality beats
> purity". I don't see True-1 in the same league though.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4