Jonathan Daugherty wrote: > # Not being funny, but this isn't actually a very good way to design > # anything. > # > # 'Most' newcomers will design a horrifically bad api if asked, because > # 'most' newcomers have no idea how to design apis. > > Maybe I should be more explicit: come up with a list of design > possibilities and ask newcomers which one(s) seem clearer, in terms of > the developement experience. Obviously asking newcomers to *design* > would not be prudent. :) >
Again, not being funny, but this is the start of a method of arguing that boils down to * suggest a huge amount of work for your 'opponent' to do * act as if you have knocked it down with a feather by finding a minor flaw, whilst ignoring all the major flaws in your own position. Please could we try to address technical issues directly for the moment, rather than coming up with new ways to combine sociology and computer science? Anyway.... The ways to deal with this that get rid of generated classes : 1) Accept the fact that most people programming in python can work out that differently named methods can have different semantics - ie class methods. 2) Class methods moved to a nested object, eg Polls.all.get_list() This would still be accessible from an instance, ie poll = Poll() poll.all.get_list() but I can't come up with any real situations in which this would matter.. 3) Still making a magic module, with the attendant functions, and importing the existing class into that namespace, instead of using the generated class. Still odd because the class gets aliased for questionable benefit. I'm sure others can come up with other methods. I would prefer 1) because its obvious, but don't really care as long as we get rid of the generated class.
