Hi W, On Aug 3, 2010, at 4:38 PM, wheres pythonmonks wrote:
I think that the crux of the matter is in points #3, #4, and #5 that you raised:
I think #2 is important too: a program is supposed to do what you expect, and I don't expect instantiation of an ABC.
On #3: Not clear that all possible specializations warrant factorization into a class. Indeed, this may result in "premature abstraction" -- and make the code less clear. Also, it will freeze in the base classes, making future refactoring a headache.
I agree (for small specializations only).
On #4: Unless I misunderstood something, there is nothing in python that ensures that a class definition is localized. So, putting definitions in classes, does not guarantee that the definition is at a single location in the code.
That's right, but with classes it is possible (and encouraged) to keep things in a single location. The other option necessarily puts things where I don't expect them.
5) why would you want a thinner class hierarchy? The yo-yo anti-patten: http://en.wikipedia.org/wiki/Yo-yo_problem I have a pretty strong preference for using a small number of useful objects, instead of having code littered with objects strewn across the namespace.
I see the point, but I would like to remark that if a program does what you expect, you won't need to understand the whole inheritance graph.
Maybe there is a Python ABC tutorial out there that can enlighten me?
http://docs.python.org/library/abc.html http://www.doughellmann.com/PyMOTW/abc/ Cheers, Roald PS: most people in this list prefer not top posting -- http://mail.python.org/mailman/listinfo/python-list
