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

[Martin v. Löwis]

Bob Halley <halley@play-bow.org> writes:

> Do people think this patch is too risky for
> 2.3 or are there plans to apply it?

Yes, it is too risky. There is no serious problem I can see that is
fixed by bug. inet_aton is a trivial function, and you can easily do

def inet_aton(s):
    if s == '255.255.255.255':
        return '\xff\xff\xff\xff'
    return socket.inet_aton(s)

> My DNS code is IPv6 aware, and must deal with IPv6 addresses, even on
> platforms which do not implement IPv6 sockets.  For example, someone
> might want to work with a zone containing AAAA records.  It would have
> been nice if the socket module always supported these routines, even
> if the platform did not.  I ended up writing my own inet_ntop/pton in
> Python.

And that's what you should do, since inet_pton/ntop don't expose any
system functionality - they are merely there for convenience.

> 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?"

I can't see how this could work, given that the underlying inet_pton
implementation might refuse to support IPv6.

> BIND has long faced the same issues with missing inet_ routines, and
> has its own C implementations of inet_aton, inet_ntop, and inet_pton.
> These are under a Historical-style open source license.  We could
> easily integrate them into Python if people thought it to be generally
> useful.  Far too risky for 2.3, but perhaps something for 2.3.1?  What
> do people think?

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

Regards,
Martin