On Wed, 30 Sep 2009 at 10:52, Paul Moore wrote:
2009/9/30 Mark Dickinson <dicki...@gmail.com>:
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
linus = IPv4Network('172.16.200.1/24')
snoopy = IPv4Network('172.16.200.3/24')
fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
fqdn[linus] ?# expecting 'linus.peanuts.net'
'snoopy.peanuts.net'
I certainly don't understand IPv4Network better than you :-) But that
just looks wrong to me - linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).
I didn't reply to Guido's post about not wanting a third class
(IPAddressWithMask or somesuch) because it made it harder for people to
choose the "right" class to use. He went on to say that if there was
only one class, they'd have a 100% chance of getting it right.
Well, the original ipaddr implementation had one class(*), but it wasn't
deemed acceptable by the community, and at least one real user
of ipaddr has expressed appreciation of the 2.0 addition of the
explicit IPAddress data type, so it seems like that was the right
direction to go.
Now the new implementation has two classes, and the above example shows
that people _will_ make the wrong choice. I'd say that was _because of_
the loose parsing and the ip attribute. If IPv4Network only accepted
valid network addresses and masks, and there was a separate parsing
function that took an arbitrary IP+netmask and returned an (IPAddress,
IPNetwork) tuple, then the user would choose the right class, IMO,
because otherwise they couldn't even get their code to parse the input.
That seems like good design to me.
But I think I'm descending to beating a dead horse here....
--David (RDM)
(*) yes, I'm ignoring the IPv4/IPv6 split throughout this message.
_______________________________________________
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
