[Python-Dev] PEP 3144 review. (original) (raw)

Peter Moody peter at hda3.com
Sun Sep 27 18:47:27 CEST 2009

On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Peter Moody <peter 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 parseaddressandmask 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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com

More information about the Python-Dev mailing list