Firstly, I noticed during the QA work for my most recent release of
dnspython that Python 2.3c1 on Windows XP still raises socket.error if
you call socket.inet_aton('255.255.255.255'). I added work-around
code to my library to avoid triggering it. Patch 756021 addresses
this (excuse the pun :)). Do people think this patch is too risky for
2.3 or are there plans to apply it?
The other thing I've had to work around is the highly conditionalized
support for IPv6 in the socket module. inet_ntop and inet_pton are
only provided if the underlying platform supports them, and IPv6
address support is only provided if the platform can actually create
an IPv6 socket.
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.
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?"
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?
/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