Daniel Stutzbach writes:
> People have voiced support for the IPNetwork class
The obvious use cases are
1. parsing and validating strings that purport to describe networks,
2. providing a received for the result of a function that deduces the
network from an arbitrary address and a mask
3. (controversial) providing the function in (2) as a method or
constructor
4. holding certain information associated with a network such as
a. broadcast address
b. (controversial) the arbitrary address from (2) (I count this as
obvious because I'm a packrat and hate to throw away any data,
but really if generated as in 2 I see no use case)
5. providing an iterator for the addresses in the network.
Note that (1) and (2) have analogous use cases for IPv?Address.
> and for the occasional utility of an .ip field. I assume they have
> good use cases.
[Please don't do that, not even ironically. 90% of the heat in this
thread has come because people discussed proposed syntax without
agreeing on a common use case to compare the semantics to.]
The only use case I can imagine for .ip is to represent a single
gateway:
def make_gateway(network, gateway):
gw = IPv4Network(network) # eg network = '192.168.1.0/0'
gw.ip = IPv4Address(gateway).ip # eg gateway = '192.168.2.1'
return gw
Note that this usage *cannot* be served by parsing "denormalized
network descriptions" as the gateway address (ie, make_gateway cannot
be a one-argument function). I did think about a use case like that
for DNS SRV records, but servers are looked up by service, not by
network, in most cases. So gateways are really the only service that
fits this model.
Also, it seems to me that this usage is well-served by the change to
the definition of __eq__ to compare .network and .prefixlen, viz.
def find_gateway_address(network, gateway_list):
"raises ValueError if no gateway known for network"
# it's interesting that there's no sequence method for this
return gateway_list[gateway_list.index(network)].ip
> I worry that this discussion has focused too much on the details of
> ipaddr (and the false dichotomy of "ipaddr versus nothing"),
It's not a false dichotomy; this PEP proposes adding ipaddr, not any
other library. Of course if ipaddr needs additional functionality, it
should be added before approval. But you seem to question whether any
of the functionality is necessary, and I don't recall any posts of the
form, "this is really sweet, but it needs salt".
> without properly tackling the question of "What use-cases for IP
> addresses are sufficiently universal* that they belong in the
> standard library?"
I think that the use cases given above are pretty universal. The
string parsing cases alone give sufficient rationale for existence of
at least one class, and since addresses and networks are conceptually
different (for me, anyway), I am happy to have two different classes.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
