[Python-Dev] PEP 3144 review.

[R. David Murray]

On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
> 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.

I don't believe anyone ever suggested adding a class that differed from
IPvXNetwork by the presence or absence of an 'ip' attribute.  The two
approaches(*) suggested were:

     1) do not add another class, just pass around (IPvXAddress,
     IPVXNetwork) tuples when the address needs to be retained (or write
     your own tailored trivial class, like I did in my example).

     2) add a class that differs from IPvXAddress by having a 'network'
     attribute that points (possibly lazily) to an IPvXNetwork object,
     and perhaps 'netmask' and 'hostmask' attributes.

Especially after my experience with writing a real example program, I
prefer (1).

--David

(*) For completeness there was also a third approach: add a 'network'
attribute to IPvXAddress that would be None if there were no associated
netmask.  Conceptual problems with this were raised which I won't
summarize; IMO it would only be slightly better than IPvXNetwork having an
'.ip' attribute.