On Fri, Mar 08, 2002 at 01:12:25PM -0500, Hans Nowak wrote:

I'm not sure if there's a lot of code out there that actually uses these numerical values. I occasionally use it, though... I guess that's what I get for bad programming practices. :-)

Hmm... I wonder if this related idiom is common? print ["false", "true"][boolvalue] --amk

Hans> This may be a minor issue, but this proposal will break code like Hans> days_feb = 28 + isleapyear(year) Hans> assuming that booleans cannot be added to ints. :-) I don't think this will be a problem. Guido's proposal is for bool to be a subclass of int. Consequently, 28 + True should yield 29 (perhaps with a warning from PyChecker). Skip

Skip Montanaro wrote:

Hans> This may be a minor issue, but this proposal will break code like

Hans> days_feb = 28 + isleapyear(year)

Hans> assuming that booleans cannot be added to ints. :-)

I don't think this will be a problem. Guido's proposal is for bool to be a subclass of int. Consequently, 28 + True should yield 29 (perhaps with a warning from PyChecker).

This gave me an idea that in general it might be useful to try to address the ways that adding a new feature might break existing code. Or other problems which may occur. I (or some other brave soul) could then use each case to add warnings to pychecker. This could help people prior to upgrading, which was a complaint I just read about on c.l.py. If the cases were in the PEP, the portability concerns could be addressed by pychecker. To start the ball rolling on this PEP, here are the issues I can think of: * User already defining true or false in various cases * Performing any binary operation (+, -, *, /, **, &, |, ^) on one or two booleans * return [01] -> false, true # thanks, samuele Neal

Skip Montanaro :

...

Guido's proposal is for bool to be a subclass of int. Consequently, 28 + True should yield 29

But True - 1 won't equal False. Should it?

No. regards.

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" To: "Greg Ewing" Cc: 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

Martin v. Loewis wrote:

Greg Ewing writes:

...

Skip Montanaro :

...

Guido's proposal is for bool to be a subclass of int. Consequently, 28 + True should yield 29

But True - 1 won't equal False. Should it?

Despite that Guido said "no" here, I think the answer is "yes", and the first sentence is wrong: True - 1 == False. True - 1 won't be identical with False, but it will be equal to it.

Sigh... Having read this huge thread now in 2.5 hours, I can't say I like this stuff too much. Why allow coercion to int at all? We can use Int(False), like we can use Bool(42). But still I think keeping Bool and Int completely disjoint types was a very well thought-out decision of Nikolas Wirth, and I wish very much that Python goes the same clean way or stays where it is! Please let's make a true type, no compromizes, no repr issues, no arithmetic operations, absolutely unrelated and really incompatible to integer, also no < relation. Python-looks-more-and-more-perlish-to-me - ly y'rs - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net/ 14163 Berlin : PGP key -> http://wwwkeys.pgp.net/ PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com/