On Wed, Sep 16, 2009 at 8:36 PM, Peter Moody <pe...@hda3.com> wrote: > On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara > <andr...@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/ >> > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
