[Python-Dev] PEP 3144 review.

[Peter Moody]

On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou <solipsis at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>