[Python-Dev] PEP 3144 review.

[Peter Moody]

On Wed, Sep 16, 2009 at 8:36 PM, Peter Moody <peter at hda3.com> 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.
>
>>>> 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
>> .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...)
>
>>>> 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.

Since you mentioned correctness; it seems like we're coming back to an
option to the IPv?Network().__init__ methods which strictly checks for
host bits being masked to zero. this provides, I think, the
functionality/error checking you're looking for w/o the need for new
classes.

Cheers,
/peter


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