[Python-3000] Traits/roles instead of ABCs

Alan McIntyre alan.mcintyre at gmail.com
Tue May 1 05:31:37 CEST 2007

On 4/30/07, BJörn Lindqvist <bjourne at gmail.com> wrote:
> On 4/30/07, Bill Janssen <janssen at parc.com> 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 <barry at python.org> 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,

More information about the Python-3000 mailing list