>This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).
Yes, I know - I was just trying to keep to the point. >It's still unclear to me what is gained by pulling AddressWithMask >functionality out of the current network classes. It's easy enough for >the concerned developer who to check if the entered network address >does actually have all of its host bits set to zero. It is not my >experience that this behavior is desired so often that having the >network classes behave as they do now leads to a great deal of >confusion. I think we're in a painful middle ground now - we should either go back to the idea of a single class (per protocol), or make the distinctions clear (networks are containers and addresses are singletons). Personally, I think I would be happy with a single class (but I suspect that's just my laziness speaking). However, I think the structure and discipline of three classes (per protocol) may actually make the concepts easier to understand for non-experts. A particular case in point - if you want to represent a single IP address with netmask (say an interface), you use a Network class, not an Address class. And the .network attribute returns a Address class! The reason I suggest having the Network class assert that masked bits be zero is two-fold: * it ensures the correct class is being used for the job * it ensures application-user errors are detected as early as possible I also suggest the AddressWithMask classes not have any network/container behaviours for a similar reason. If the developer needs these, the .network attribute is only a lookup away. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ _______________________________________________ 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
