On 4/30/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 4/30/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > +1 for preferring simple solutions to complex ones > > > > Me, too. But which is the simple solution? I tend to think ABCs are. > > Neither or. They are both an order of a magnitude more complex than > the problem they are designed to solve. Raymond Hettingers small list > of three example problems earlier in the thread, is the most concrete > description of what the problem really is all about. And I would > honestly rather sort them under "minor annoyances" than "really > critical stuff, needs to be fixed asap."
Disclaimer: I've only tangentially followed this entire ABC discussion, and I'm commenting off the cuff without having read as much as I probably should have. I am not a "power user" of Python (by which I mean, I've never been tasked to solve a problem using Python that made want to use abstract classes, or tinker with how the isinstance or issubclass functions do their thing). That said, the impression that I get from some of the discussions here is that big helpings of complexity might get added to the core of the language, and that's just a little unsettling to me. Maybe it's just that I don't have to solve the sorts of problems as advocates of these ideas, or I just don't have an adequate background to understand how really useful these additions would be. On 4/30/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Interfaces and ABCs are really all about Programming in the Really > Large. Most Python programs don't need this stuff, and in fact, > having to deal with them in any way would IMO reduce the elegance of > Python for small to medium (and even most large) applications. I think this is what's generally bugging me: the impression that there's a push to add features to help out those that program in The Really Large, or in The Really Mathematical (rings and semigroups and monoids, oh my!). I have a nagging concern that these additions will clutter up the core, and--no matter how hard you try--adding them is going to have an impact on "run-of-the-mill" users of the language. My-2-cents'ly yours, Alan _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
