[Python-Dev] PEP 3144 review.

[Mark Dickinson]

On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mark Dickinson wrote:
>> Okay, so maybe this is an abuse of IPv4Network.  But I'd (mis?)understood
>> that the retention of the .ip attribute was precisely a convenience to allow
>> this sort of use.  If not, then what's it for?  I've read the PEP and almost
>> all of this thread, but I can't help feeling I'm still missing something.  If
>> someone could point out the obvious to me I'd be grateful.
>
> You're not missing anything that I'm aware of - unlike the use case for
> accepting a denormalised network definition in the IPNetwork constructor
> (which has been made quite clear in the list discussion, even if it is
> still a bit vague in the PEP), the use case for *retaining* the host
> information on the network object hasn't been well articulated at all.
>
> The closest anyone has come to describing a use case is an indirect
> comment via Guido that leaving out the attribute would involve real code
> having to find somewhere else to stash the original address details
> (e.g. by passing around an IPAddres/IPNetwork tuple rather than just an
> IPNetwork object).

Ah, thanks---I'd missed that bit.  So the .ip attribute is mainly for
backwards compatibility with existing uses/users of ipaddr.  I guess
that makes sense, then.  In particular, if it's suggested that new code
shouldn't make use of the .ip attribute, then the list/dict membership
problems described above can't arise.

> However, while I'd still be a little happier if the .ip attribute went
> away all together and another means was found to conveniently associate
> an IPAddress and an IPNetwork, keeping it doesn't bother me anywhere
> near as much as having network equivalence defined in terms of something
> other than the network ID and the netmask.

Makes sense.

Thanks,

Mark