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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4