I am never going to complain about Python again

[Joshua Landau]

On 11 October 2013 10:11, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 11 Oct 2013 09:17:37 +0100, Joshua Landau wrote:
>
>> On 11 October 2013 03:08, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>>
>>> Given:
>>>
>>> x ∈ ℝ, x = 2  (reals)
>>> y ∈ ℕ, y = 2  (natural numbers)
>>>
>>> we have x = y, but since 1/y is undefined (there is no Natural number
>>> 1/2), 1/x != 1/y.
>>
>> Surely 1/y is perfectly well defined, as only y, not 1/y, is constrained
>> to the natural numbers.
>
> Context is important, and usually implied. 1/y within the natural numbers
> is treated in the same way as sqrt(-1) within the reals.

I don't know; a rational tends to be described as any number of the
form x/y where x, y ∈ ℕ. Hence I don't agree that it's reasonable to
ever assume that 1/y has to exist in the same space as y unless
explicitly stated or generally working within, say, the integers.
Neither of those are remotely true of Python so I don't see how this
point is relevant when discussing Python's concept of equality.

> Try it on your
> calculator, and chances are very good you'll get an error. Try it in
> Python 2, or nearly any other programming language (but not Python 3),
> and again, chances are you'll get an error.

*Remains unconvinced.* None of that seems to actually matter.

> If you implicitly decide to promote entities, then of course you can
> promote y to a real then take the invoice.

I'm not. I'm just not applying the restrictions on y to the function it's in.

> But that trick still doesn't
> work for the original example, int(0.0) == int(0+0j) because promoting 0
> to complex doesn't help, you have to demote 0+0j to real and that's
> ambiguous.

I agree on this. The correct interpretation of

    0.0 == 0 + 0j

is, of course

    complex(0.0) == 0 + 0j