Unify addresses passed to bind() and getaddrinfo()
...when using bind(): HOST = "" # Symbolic name meaning all available interfaces ...when using getaddrinfo(): HOST = None # Symbolic name meaning all available interfaces I recently got bitten by this difference in that I passed "" (empy string) to getaddrinfo() and since my DNS server was temporarily down getaddrinfo() hung indefinitely (cset where I fixed this: https://code.google.com/p/pyftpdlib/source/detail?r=1194#). It took me quite some time to figure out what was wrong as to me "" has always been an alias for "all interfaces" and didn't know getaddrinfo() behaved differently than bind() in this regard. If from getaddrinfo() standpoint "" (empty string) has no particular meaning I propose to unify the two APIs and make getaddrinfo() assume "" is an alias for "all interfaces". Thoughts? --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/
On Mon, Mar 11, 2013 at 12:20 PM, Giampaolo Rodolà <g.rodola@gmail.com>wrote:
I agree this difference in behavior seems a little confusing, and is arguably odd considering that bind() uses getaddrinfo() internally.. At the very least, I do believe that if getaddrinfo() accepts None to indicate "all local interfaces", that bind() should also accept None for this purpose as well. I don't think this would be a difficult change and I can't see any real downside to allowing it. The only concern I see with going the other direction (making getaddrinfo() consider an empty string to be the same as None), as you suggest, is that this would technically not make it work the same as the underlying system call, which does treat "" and NULL as meaning different things. It is true that in the typical Unix/Windows/MacOS case using the standard hosts/DNS resolvers, an empty hostname has no real meaning, but technically that is not necessarily true for all possible types of name services that an OS might provide, and it is possible that there's a name resolver out there for which specifying "" as the hostname actually does mean something important. Theoretically, this sort of change would make such a system not work as expected (possibly in non-obvious ways) when accessed from Python.. Personally, though, I do think it would make sense to change bind() to allow None as an argument, and make that the preferred way to specify "all interfaces" (still allowing an empty string as another way to say the same thing). It would make it more consistent with getaddrinfo, as well as also making it more Pythonic, IMHO.. --Alex
Agreed, but now that I look at how getsockaddrarg() is implemented into socketmodule.c I'm kind of scared of what could happen if we blindly change/force the original tuple passed by the user in case of exotic families such as AF_NETLINK, AF_BLUETOOTH and others (I have no idea what kind of address tuple (?) is supposed be passed in those cases). Alternatively we might change it only for AF_INET sockets but it seems kind of inconsistent and doesn't probably worth the effort. --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ 2013/3/13 Alex Stewart <foogod@gmail.com>:
On Mon, Mar 11, 2013 at 12:20 PM, Giampaolo Rodolà <g.rodola@gmail.com>wrote:
I agree this difference in behavior seems a little confusing, and is arguably odd considering that bind() uses getaddrinfo() internally.. At the very least, I do believe that if getaddrinfo() accepts None to indicate "all local interfaces", that bind() should also accept None for this purpose as well. I don't think this would be a difficult change and I can't see any real downside to allowing it. The only concern I see with going the other direction (making getaddrinfo() consider an empty string to be the same as None), as you suggest, is that this would technically not make it work the same as the underlying system call, which does treat "" and NULL as meaning different things. It is true that in the typical Unix/Windows/MacOS case using the standard hosts/DNS resolvers, an empty hostname has no real meaning, but technically that is not necessarily true for all possible types of name services that an OS might provide, and it is possible that there's a name resolver out there for which specifying "" as the hostname actually does mean something important. Theoretically, this sort of change would make such a system not work as expected (possibly in non-obvious ways) when accessed from Python.. Personally, though, I do think it would make sense to change bind() to allow None as an argument, and make that the preferred way to specify "all interfaces" (still allowing an empty string as another way to say the same thing). It would make it more consistent with getaddrinfo, as well as also making it more Pythonic, IMHO.. --Alex
Agreed, but now that I look at how getsockaddrarg() is implemented into socketmodule.c I'm kind of scared of what could happen if we blindly change/force the original tuple passed by the user in case of exotic families such as AF_NETLINK, AF_BLUETOOTH and others (I have no idea what kind of address tuple (?) is supposed be passed in those cases). Alternatively we might change it only for AF_INET sockets but it seems kind of inconsistent and doesn't probably worth the effort. --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ 2013/3/13 Alex Stewart <foogod@gmail.com>:
participants (2)
-
Alex Stewart -
Giampaolo Rodolà