[Python-Dev] PEP 3144 review.
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
> > 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).
> 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.
More information about the Python-Dev