[Python-ideas] Unify addresses passed to bind() and getaddrinfo()

[Alex Stewart]

On Mon, Mar 11, 2013 at 12:20 PM, Giampaolo Rodolà <g.rodola at gmail.com>wrote:

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130313/37ae24a2/attachment.html>