[Python-Dev] PEP 3144 review.

[Terry Reedy]

This is my first post in this thread. I do not currently expect to 
directly use ipaddr, but I am interested in Python having good modules 
and a friendly development environment.

It strikes me that a module that meets the desiderata of broad community 
support is going to have the 'baggage' of lots of users, who will not 
want current code broken. So that criterion conflicts with the desire to 
do major redesign.

Peter Moody wrote:

>   re: assumed disconnect between the statement "Addresses and Networks
> are distinct" and the implementation.
> 
> I don't actually see a disconnect.

I can, at least somewhat. But I do not think philosophical agreement is 
either possible or needed for practical compromise. There will still 
remain the issue of how the doc is organized and worded (see below).

>   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"
> 
>   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?

To my naive viewpoint, yes and mostly no, and if Guido say yes and no, 
that would also be good enough for me. I do not think the cognitive load 
of .ip on learning the module is any greater than having a third class, 
especially if it is somewhat isolated in the doc as suggested below.

My suggestion for the doc, based on my understanding derived from 
reading this thread (and therefore subject to correction ;-) is 
something as follows:

-----

NN. IPADDR

NN.1 Adresses ....

NN.2 Networks

Conceptually, a network is a power of 2 range of addresses whose last k 
bits range from 0...0 to 1...1. A network object is similar to a Py3 
range object. Networks are often (usually? always?) defined by an 
address plus an indication of the bits to either keep or ignore.

As a convenience for certain uses, the defining address is included with 
the network instance as its .ip attribute (see NN.3 Address + network). 
However, standard comparisons ignore this attribute, as do the methods 
discussed in this section.

...

NN.3 (or possibly NN.2.1) Address (or Host) + Network

As mentioned above, Network instances include their defining address as 
a .ip attribute so that they can alternatively be used as Host+Network. 
The following functions and methods use this attribute. ...

-------

In other words, I suggest the the doc be organized more or less as it 
would be if there were a third class. I believe this would help both 
those who do not need or want this usage, as well as those who do.

Terry Jan Reedy