[Python-Dev] PEP 3144 review.

[Guido van Rossum]

On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Mon, 28 Sep 2009 at 22:11, "Martin v. Löwis" wrote:
>>>
>>> Martin v. Löwis <martin <at> v.loewis.de> writes:
>>>>>
>>>>> Could you explain what benefit there is for allowing the user to create
>>>>> network objects that don't represent networks? Is there a use-case
>>>>> where these networks-that-aren't-networks are something other than a
>>>>> typo? Under what circumstances would I want to specify a network as
>>>>> 192.168.1.1/24 instead of 192.168.1.0/24?
>>>>>
>>> [...]
>>>>
>>>> So Python code has to make the computation, and it seems most natural
>>>> that the IP library is the piece of code that is able to compute a
>>>> network out of that input.
>>>
>>> The thing is, it doesn't create a network, it creates a hybrid "network
>>> plus
>>> host" which retains knowledge about the original host (that is,
>>> 192.168.1.1
>>> rather than simply 192.168.1.0, if you enter "192.168.1.1/24").
>>>
>>> That's what the OP meant with "networks-that-aren't-networks", and that's
>>> what
>>> people are objecting to.
>>
>> That's not the question that was asked, though - the question asked
>> was "Under what circumstances would I want to specify...". I hope
>> most people agree that it is desirable to be able to specify a network
>> not just by its network address.
>
> But then it's not a network, it is an ipaddress-plus-mask.  It is exactly
> that conflation that we are objecting to.  There is no question about
> the use case of _specifying_ a network ip plus a netmask and deriving
> a network object from that.  That is unquestionably required by any
> useful API.  The argument is about whether the object returned is a
> Network object, or a hybrid object representing _both_ an IP address
> and a network.  It is the latter, which ipaddr does, which many of us
> find problematic and likely to lead to hard to read programs that will
> probably produce maintenance errors.
>
> I observe that this line in the current PEP rationale:
>
>    IP addresses and IP networks are distinct.
>
> is not in fact achieved by the reference implementation.  Peter, however,
> clearly thinks it is, since it is listed as a design goal of ipaddr.
> This is a language disconnect I don't understand, which I think has
> been the source of a lot of the difficulties in this thread.

I say the case has been argued extensively, let's wait for Peter to respond.

I would say that there certainly are precedents in other areas for
keeping the information about the input form around. For example,
occasionally it would be handy if parsing a hex integer returned an
object that was compatible with other integers but somehow kept a hint
that would cause printing it to use hex by default.

I see keeping around the IP address used to create a network object as
a similar edge case. I would probably define the __eq__ method to
implement equivalency (ignoring the form of the input), just as I
would in the case of the (hypothetical) hex integers. If you wanted to
do a comparison that includes the input IP address, you could use (a,
a.ip) == (b, b.ip).

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