On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull <step...@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 .denormalized_compare() 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. > > _______________________________________________ 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