On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan <ncogh...@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 _______________________________________________ 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