[Python-Dev] PEP 3144 review. (original) (raw)
Andrew McNamara andrewm at object-craft.com.au
Thu Sep 17 06:17:45 CEST 2009
- Previous message: [Python-Dev] PEP 3144 review.
- Next message: [Python-Dev] PEP 3144 review.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
It's mostly just minor refactoring and renaming, which I think makes things clearer, although I agree this is merely an opinion. I would be interest to hear what others think. To summarise:
an address is a singleton (a network endpoint), with no container behaviour. It may optionally reference it's network (via the .network attribute), .address returns mask-less address.
a network is a container-like object. For consistency, .network should return self and raise an exception if the mask conflicts with the address, .address returns the base address, .mask returns 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 .networkaddress and .broadcastaddress less confusing? I have to say, though, .network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4 use, IIRC .network...)
Yes, I understand your motivation, but I still think it's going to be more confusing the way you have it.
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.
Certainly, I'm not talking about adding functionality. What I am suggesting is that if we wish to have a distinction between networks and addresses, then that distinction should be clear and strong, such that the choice of which to use is obvious, and if the wrong one is used, the error is discovered as early as possible.
As the module stands, we have a pair of address-without-mask classes called *Address, and a pair of address-with-mask classes called *Network. So, sometimes when you want to record an address you use a class called Network, and that class comes with a behaviours that make no sense in the context of a singleton network end-point (it can't "contain" other addresses, although it's .network can).
Sorry if I sound like a cracked record - these are subtle concepts, and my ability to explain what I mean is less than is needed, but we'll get there in the end.
-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
- Previous message: [Python-Dev] PEP 3144 review.
- Next message: [Python-Dev] PEP 3144 review.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]