[Python-Dev] PEP 3144 review. (original) (raw)

Scott Dial scott+python-dev at scottdial.com
Thu Sep 17 05:53:12 CEST 2009

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

More information about the Python-Dev mailing list