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