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

Andrew McNamara andrewm at object-craft.com.au
Thu Sep 17 03:32:19 CEST 2009

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:

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/

More information about the Python-Dev mailing list