for / while else doesn't make sense

[Chris Angelico]

On Mon, May 23, 2016 at 1:52 AM, Jon Ribbens
<jon+usenet at unequivocal.co.uk> wrote:
> That's a circular argument. You're defining the result as the
> requirement and then saying that proves the result is necessary.
> Clearly, people managed when 1/2 returned 0, and continue to do so
> today in Python 2 and other languages.
>

Python's int and float types are both approximations to a
non-representable type called a "real number". You learned about
numbers in your early childhood - you learned about the basic concepts
like addition (you have one apple here and one apple there, so you
have two apples), and division (you take those two apples and split
them between four people by cutting them both in half). If you ask
someone how much apple everyone gets when you divide one apple between
two people, the answer should be "half an apple". Not "no apples" - of
course there are situations where things are indivisible, but numbers
themselves aren't, because there are times when you can indeed halve
those apples just fine.

The problem is that computers can't actually represent real numbers.
We have to content ourselves with a variety of approximations, which
we call numeric data types. Python then treats those data types as
being a minor detail, and the underlying real number as important:

>>> 1 == 1.0 == (1+0j)
True
>>> {1.0: "foo"}[1]
'foo'

Now, there is the small problem that the numeric types can't be
arranged into a perfect tower. If Python's integer were restricted to
2**32, you could automatically upcast any integer to a float
losslessly, and you can already losslessly upcast a float to a complex
simply by adding 0j to it. But most people don't work with numbers big
enough to be unrepresentable in 64-bit IEEE floating point:

>>> (1<<53)+1
9007199254740993
>>> (1<<53)+1 == (1<<53)
False
>>> (1<<53)+1.0 == (1<<53)
True

So for *most people*, this treatment works perfectly. An int will
upcast to a float when you apply the division operator to it. An int
or float will upcast to complex when you apply the exponentiation
operator:

>>> (-4)**0.5
(1.2246467991473532e-16+2j)

Nearly everything stored in a computer is an abstraction that can
leak. In this case, we can't perfectly represent real numbers or
calculate with them, so we do the best we can. Binary floating point
is far from perfect in purity, but it's not bad in practicality.
Remind me what PEP 20 says about that? Gotcha.

ChrisA