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

Peter Moody peter at hda3.com
Tue Sep 29 20:28:07 CEST 2009

On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

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

no, I mean setting it up so that if I want to compare two network objects and take into account their .ip attribute, that I use a .compare_with_extra_bits() method or something. eq, ne, lt, le, gt, ge (any more?) would all only compare .network and .prefixlen (as you have in your example).

Cheers, /peter

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 .denormalizedcompare() 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.

More information about the Python-Dev mailing list