On Wednesday, April 9, 2003, at 09:37 AM, Guido van Rossum wrote:
OK, I'll chime back in on the thread I started... I mostly have a question for Sean, since he seems to know the networking stuff well.
I'll chime in nevertheless.
Do you know of any reason why my original proposal (which is to allows IP addresses prefixed with <numeric> e.g. <numeric>127.0.0.1 to cause both the AI_PASSIVE _and_ AI_NUMERIC flags to get set when resolution is attempted, which basically causes parsing with not real resolution at all) would break any known or plausible networking standards?
What are those flags? Which API uses them?
The getsockaddr call uses them (actually the correct name for one of the flags is AI_NUMERICHOST, not AI_NUMERIC as I originally stated), and its part of the BSD sockets library, which is basically what the python socketmodule wraps.
I still don't understand why intercepting the all-numeric syntax isn't good enough, and why you want a <numeric> prefix.
I guess intercepting all numeric is OK, it is just less efficient (since it requires a trial parsing of an address, which is wasted if it is not all numeric), and because it is so easy to implement <numeric>. However, all my operational goals are achieved if the old check for pure numeric is reinstated at the lowest level (probably in getsockaddrarg in socketmodule.c), so it is used everywhere.
The current Python socket module basically hides this part of the BSD socket API, and I find it quite useful to be able to suppress DNS activity absolutely for some addresses. And for Guido: since this type of tag has already been used in Python (as <broadcast>), is there any reason why this solution is inelegant?
The reason I'm reluctant to add a new notation is that AFAIK it would be unique to Python. It's better to stick to standard notations IMO. <broadcast> was probably a mistake, since it seems to mean the same as 0.0.0.0 (for IPv4). I accept this logic. However, python is hiding a very useful (for efficiency) piece of the API, or depending on guessing whether you want it or not by looking at the format of an address. There are times in higher-level (python) code where getaddrinfo is called to get a CNAME, where I would also like to cause the raw IP to be returned by force, instead of attempting to get a CNAME, since I already know, by the IP I chose, that one doesn't exists. If we make the same check for numeric IPs in getaddrinfo, then it becomes impossible to resolve numeric names back to real ones. There is not way for getaddrinfo to know which way we want it, since in this case both ways might be needed.