Peter Moody 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.
Speaking as the originator of this thread of discourse, the lack of a 3rd class was exactly the source of my confusion and my inability to communicate my confusion to everyone. I clearly did not understand the intended uses of the IPNetwork type because it was capable of playing two roles that are decidedly different conceptually. So, I must respectfully disagree with you. >>> 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. This is exactly the confusion and duality that I struggled with. >> 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. The purpose is to avoid conflating IPNetwork with an IPAddress that has a mask. If the IPNetwork didn't accept a non-zero host and instead required a developer to use a helper to construct a IPNetwork with a proper address, then there would be less confusion about what exactly a IPNetwork is meant to represent. As it stands, it's purposes is muddled by accepting host addresses too. I am rather indifferent whether there needs to be a IPAddressWithMask type. If that is needed, then it is rather easy to create a type that does that. And, if it is a common pattern, then it could be added to the module later in life. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu _______________________________________________ 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