[Python-Dev] PEP 3144 review. (original) (raw)

Terry Reedy tjreedy at udel.edu
Tue Sep 29 23:05:27 CEST 2009

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

More information about the Python-Dev mailing list