[Python-Dev] PEP 3144 review.
peter at hda3.com
Tue Sep 29 17:36:02 CEST 2009
Responding to a few points here. David and I were discussing these
points off-list, I didn't mean to ignore.
re: assumed disconnect between the statement "Addresses and Networks
are distinct" and the implementation.
I don't actually see a disconnect. it seems analogous to stating
lists and ints are distinct yet lists can still contain ints. networks
and addresses are distinct and yet networks contain addresses.
re: denormalized networks:
I've mentioned at least once (and others have mentioned as well) that
it's very common, when describing the ip address/prefix of a NIC to
re: new comparison methods
this is interesting. I would be open to doing this and making __lt__,
__gt__, __eq__ and friends do the non-ip comparing by default. would
this be sufficient or does the fact that the network has the .ip
attribute break something pythonic?
On Mon, Sep 28, 2009 at 1:43 PM, Guido van Rossum <guido at python.org> wrote:
> 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
>>>> host" which retains knowledge about the original host (that is,
>>>> 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
>>>> 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/)
More information about the Python-Dev