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
_______________________________________________
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
