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>.
The performance loss will be unmeasurable (parsing a string of at most 11 bytes against a very simple pattern). Compare that to the true cost of adding <numeric>: documentation has to be added (and dozens of books updated), and code that wants to use numeric addresses has to be changed.
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.
Right.
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.
You're right, this functionality should be made available. IMO the right solution is to make it a separate API in the socket module, not to add more syntax to the existing address parsing code. --Guido van Rossum (home page: http://www.python.org/~guido/)