On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy <tjre...@udel.edu> wrote: >> 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? > > To my naive viewpoint, yes and mostly no, and if Guido say yes and no, that > would also be good enough for me.
Indeed I say yes and no. > I do not think the cognitive load of .ip > on learning the module is any greater than having a third class, especially > if it is somewhat isolated in the doc as suggested below. Here I disagree. I want users to have few choices of data types, since they usually make the wrong choice (Ever tried to figure out whether to use an ArrayList or a LinkedList in Java?) So if there are two different but similar classes to represent a network, distinguished only by whether they retain the denormalized input address or not, users have a 50% chance of picking the wrong one, while if there is only one class, there is a 100% chance of picking the right one. (There is still the IPAddress class, but the differences between IPAddress and IPNetwork are much clearer.) -- --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
