[Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

Let me first say that the module is overall quite nice; the
implementation seems concise and very efficient, and the API is
well-balanced.  I'm sorry there's been such controversy (and for my
part in it, as I managed to completely misunderstand what you
absolutely require), when AFAICT the only "line in the sand" is being
drawn around the semantics of "net1 == net2".

Peter Moody writes:

 > I don't actually see a disconnect.  it seems analogous to stating
 > lists and ints are distinct yet lists can still contain ints. networks
 > and addresses are distinct and yet networks contain addresses.

AIUI, the disconnect is that lists do not contain a distinguished
element such that if that element differs, the lists differ.  Ie, the
disconnect is the very presence of the .ip attribute in IPv?Network.
ISTM that all of the vehement opposition is related to this single
feature.

 >   re: denormalized networks:
 > 
 > I've mentioned at least once (and others have mentioned as well) that
 > it's very common, when describing the ip address/prefix of a NIC to
 > write, "192.168.1.100/24"

Please be careful to distinguish between "denormalized descriptions of
networks" (strings like your example above) and "denormalized network
objects" (ie, objects where net.ip != net.network).  I'm happy with
the former, with a slight preference for a separate method to do the
parsing, as in Antoine's proposal.  The latter makes me "unhappy", but
I'll deal with that simply by refusing to use that feature (see below).

 >   re: new comparison methods
 > 
 > this is interesting. I would be open to doing this and making __lt__,
 > __gt__, __eq__ and friends do the non-ip comparing by default. would
 > this be sufficient or does the fact that the network has the .ip
 > attribute break something pythonic?

What do you mean, "by default"?  Surely you don't mean an equality
method with some sort of flag!?

Personally I want "net1 == net2" to have the same value as
"(net1.network, net1.prefixlen) == (net2.network, net2.prefixlen)"
when net1 and net2 are IPv?Networks, period.  For me, this is the only
sticking point; if it's not true, I'll never use this module, and I'd
oppose adding it to stdlib.

I don't care if the .ip attribute *exists* (and I don't care if you
provide separate .denormalized_compare() methods) but I find the
presence of .ip in IPv?Network objects counterintuitive.  Enough so
that if I need such an object, I will create a new class (with a name
that expresses its purpose to me) to manage it in my app, if such a
class isn't provided by ipaddr.py.

That would be no great burden to me since AFAICS apps that need such
behavior are quite specialized.  In any case, it seems that many
developers (you, GvR, and MvL, at least) aren't bothered by
overloading the IPv?Network class as you do in ipaddr.py.  (In fact,
IIUC you don't even see using it for denormalized networks as
overloading.)  I see no point in getting in your way.