2009/9/17 Peter Moody <pe...@hda3.com>: > 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.
For what it's worth, Andrew's making the distinction clatified things for *me*. Whether I am the target audience for the module (I'm not a network expert, but on the odd occasion I need to manipulate IP addresses in a program, and if the standard library had a module for doing so, I'd reach for it) is up to someone else to decide, but if I am, then my vote is for 3 classes based on the explanations I've seen so far. I don't see what having fewer classes buys me as the end user. Paul. _______________________________________________ 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
