[Python-Dev] PEP 3144 review.

[Andrew McNamara]

>> 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.
>
>I think this is where we disagree. I don't think the added complexity
>does make it any easier to understand.

I argue that we're not actually adding any complexity: yes, we add
a class (per protocol), but we then merely relocate functionality to
clarify the intended use of the classes.

>> 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!
>
>Right, and I don't see where the confusion lies.  

I suggest you are too close to the implementation to be surprised by it. 8-)

>You have an address + netmask. ergo, you have a Network object.  

In a common use case, however, this instance will not represent a
network at all, but an address. It will have container-like behaviour,
but it should not (this is a property of networks, not addresses). So
the instance will be misnamed and have behaviours that are, at best,
misleading.

>The single address that defines the base address (most commonly referred
>to as the network address) is an Address object. there is no netmask
>associated with that single address, ergo, it's an Address object.

I would argue that a Network never has a single address - by definition,
it has two or more nodes. A .network attribute should return a Network
instance. If you want the base address, this probably should be called
.base_address or just .address (to parallel the .netmask attribute).

>> 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.
>
>the problem I have with this approach is that it seems like a long way
>to go for a shortcut (of checking if addr.ip != addr.network: raise
>Error).

This isn't about shortcuts, but about correctness... having the Network
object represent a network, and having Address objects represent
end-points, and having errors discovered as early as possible.

What I'm arguing here is that singletons should not simultaneously be
containers - it's not pythonic, and it leads to ambiguity. The underlying
IP concepts don't require it either: an IP address is a singleton, a
network is a container, and there is no overlap. Yes, an address may be a
member of a network, and having a reference to that network on the address
object is valuable, but the address should not behave like a network.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/