[Python-Dev] PEP 3144 review.

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

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

More information about the Python-Dev mailing list