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 write, "192.168.1.100/24" 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? Cheers, /peter On Mon, Sep 28, 2009 at 1:43 PM, Guido van Rossum <gu...@python.org> wrote: > On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray <rdmur...@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/) > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
