On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > Peter Moody <peter <at> hda3.com> writes: >> >> To be explicit though, unless I'm drastically misreading what you're >> asking for, I consider the design you're proposing to be broken from a >> usability perspective (striving for academic/pedantic correctness over >> accepted practice). > > It is certainly not academic correctness, it is concern over the > understandibility of the library. The behaviour you are proposing is > confusing, > and even if you think it is more practical (which I doubt it is), it should > still be avoided IMO. While "192.168.1.2/24" may be an accepted notation in > some > situations, it is not a notation for a *network* but for an (address, mask) > pair, or an (address, network) pair. > > There was a proposal to have a separate parse_address_and_mask method which > would return a (Address, Network) tuple, I still don't know why you don't seem > to consider it seriously, rather than trying to make the Network class a kind > of > all-in-one type conflating different concepts.
The reason (aside from the name) that I'm not going to include this in ipaddr is that it would require the user to deal with two objects when one would suffice. It's similar to getting two return values from float(). integer, fraction = float('1.25') crazy, right? Finally, to Stephen's point about seeing the other side of the argument, I wrote this offlist a week ago: I *understand* what you're saying, I *understand* that 192.168.1.1/24 isn't a network, 192.168.1.0/24 is a network, and 192.168.1.1 is an ip address on that network and it has an associated netmask that helps describe its network, etc. etc. what I'm saying is that, enforcing that restriction by introducing 2 new classes (ipv4 is not comparable with ipv6, I've actually got a good quote from Vint Cerf about this, so any AddressWithNetmask (?!?) class would have to be duplicated for both addr types) or something else as of yet described, is not useful. it is in fact, detrimental (optionally enforcing that restriction via an argument to the Network constructors is, however, useful) Cheers, /peter > Regards > > Antoine. > > > _______________________________________________ > 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/python-dev%40hda3.com > _______________________________________________ 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