[Python-Dev] PEP 3144 review.
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