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