martin@v.loewis.de (Martin v. L=C3=B6wis) writes:
> > I'm not sure how many other people will have similar needs, but I
> > think it's worth at least asking the question: "Should we always
> > provide these routines, including their IPv6 support?"
>=20
> I can't see how this could work, given that the underlying inet_pton
> implementation might refuse to support IPv6.
It would only work if Python implemented the routines itself (in Python
or in C).
> I don't want to include more C code for stuff that is
> a) trivial,
> b) provided as a library function on many systems, and
> c) can be implemented in pure Python
inet_ntop and pton are not trivial for IPv6 addresses due to the
variety of textual representations required to be accepted as
valid input, e.g.:
1080::8:800:200C:417A
ffff:0000:0000:ffff:0000:0000:0000:ffff
ffff:0:0:ffff::ffff
::1
::
0:0:0:0:0:0:13.1.68.3
A good implementation must also detect and reject all of the invalid
cases, such as improper use of the "::" zero compression syntax.
Finally, there is the desire to generate appropriately "minimized"
output when converting back to text (the two "ffff" examples above are
the same address; the second is the appropriately minimized form).
I'm not saying it's rocket science; I'm just saying it's sufficiently
nontrivial that you don't want everyone who needs the functions to have
to write them themselves.
It may be that the right answer is that not enough people care about
working with IPv6 addresses on non-IPv6 platforms to make doing
anything worthwhile. I don't know who (other than me) might care
about the issue, which is why I asked :).
/Bob
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4