[Python-Dev] PEP 3144 review.

[Scott Dial]

Peter Moody wrote:
> On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
> <andrewm at object-craft.com.au> wrote:
>>>> 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.
> 
> And I argue the moving this functionality to new classes (and adding
> new restrictions to existing classes) doesn't buy anything in the way
> of overall functionality of the module or a developer's ability to
> comprehend intended uses.

Speaking as the originator of this thread of discourse, the lack of a
3rd class was exactly the source of my confusion and my inability to
communicate my confusion to everyone. I clearly did not understand the
intended uses of the IPNetwork type because it was capable of playing
two roles that are decidedly different conceptually. So, I must
respectfully disagree with you.

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

This is exactly the confusion and duality that I struggled with.

>> 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.
> 
> Then what I don't see is the purpose of your
> network-only-network-object. essentially identical functionality can
> be obtained with the module as is w/o the added complexity of new
> classes.

The purpose is to avoid conflating IPNetwork with an IPAddress that has
a mask. If the IPNetwork didn't accept a non-zero host and instead
required a developer to use a helper to construct a IPNetwork with a
proper address, then there would be less confusion about what exactly a
IPNetwork is meant to represent. As it stands, it's purposes is muddled
by accepting host addresses too.

I am rather indifferent whether there needs to be a IPAddressWithMask
type. If that is needed, then it is rather easy to create a type that
does that. And, if it is a common pattern, then it could be added to the
module later in life.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu