[Python-Dev] PEP 3144 review.

[Peter Moody]

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