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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
