[Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton}

[Guido van Rossum]

> 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 :).

But the number of people who care will grow.  Let's leave 2.3 alone
because it's so close to release time, but I trust you (Bob) to come
up with a review of the existing socket module and suggest
improvements in API that will improve its usability and decrease its
maintenance needs.

--Guido van Rossum (home page: http://www.python.org/~guido/)