[Python-Dev] PEP 3144 review.

[Andrew McNamara]

>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/