[Python-Dev] PEP 3144 review.

Andrew McNamara andrewm at object-craft.com.au
Thu Sep 17 06:17:45 CEST 2009


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

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/


More information about the Python-Dev mailing list