[Python-Dev] _socket efficiencies ideas
Guido van Rossum
Wed, 09 Apr 2003 11:20:39 -0400
> > 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
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
> 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
> > 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/)