[Python-Dev] PEP 3144 review. (original) (raw)

Guido van Rossum guido at python.org
Wed Sep 30 22:11:12 CEST 2009

On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson <dickinsm at gmail.com> wrote:

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.

I don't know -- this is (from what Peter told me) a common use case so he (and presumably others) would from time to time have to write extra code to keep track of that IP address in a new app. Since this is just one extra attribute on an IPNetwork object I don't think that adding extra classes which only differ from the IPvXNetwork classes in having this one extra attribute is worthy.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list