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

Peter Moody peter at hda3.com
Thu Sep 17 05:36:28 CEST 2009

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.

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

touche :)

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 .baseaddress or just .address (to parallel the .netmask attribute).

.network is shorthand for network address. are .network_address and .broadcast_address less confusing? I have to say, though, .network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4 use, IIRC .network...)

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.

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.

Cheers, /peter

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/

More information about the Python-Dev mailing list