[Python-Dev] PEP 3144 review.
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.1 Adresses ....
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