[Python-ideas] Give ipaddresses an __index__ method

[Steven D'Aprano]

On Thu, Feb 15, 2018 at 01:39:13PM +1000, Nick Coghlan wrote:

> There are tests that ensure IP addresses don't implement __index__,
> and the pragmatic reason for that is the downside you mentioned: to
> ensure they can't be used as indices, slice endpoints, or range
> endpoints.

If it is an intentional decision to disallow treating IP addresses as 
integers implicitly, I guess that is definite then. No change. I can see 
that this is a reasonable decision for pragmatic reasons.

However, for the record (and under no illusion that I'll change your 
mind *wink*) ...


> While IP addresses can be converted to an integer, they are
> *not* integers in any mathematical sense, and it doesn't make sense to
> treat them that way.

I really don't think this is strictly correct. IP addresses already 
support adding to regular ints, and conceptually they are indexes into a 
32-bit or 128-bit space. They define "successor" and "predecessor" 
relations via addition and subtraction, which is pretty much all you 
need to build all other int operations from, mathematically speaking. 
(Actually, you don't even need predecessor.) I think there's a good case 
to make that they are ordinal numbers (each IP address uniquely 
specifies a logical position in a sequence from 0 to 2**32-1).

Python ints already do quadruple duty as:

- ordinal numbers, e.g. indexing, "string".find("r");

- cardinal numbers, e.g. counting, len("string");

- nominal numbers, e.g. id(obj);

- subset of the Reals in the numeric tower.

But anyway, at this point the discussion is getting rather esoteric. 
I accept the argument from pragmatism that the benefit of supporting 
__index__ is less than the disadvantage, so I think we're done here :-)



-- 
Steve