                                                                                                                                                                                                                                                                
Path: t10ni23619476pbh.0!nntp.google.com!news.glorb.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Sat, 06 Oct 2012 15:45:23 -0700
From: Demian Brecht <demianbre...@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Trent Nelson <tr...@snakebite.org>
Subject: Re: Are ABCs an anti-pattern?
References: <506AF8C9.8060...@gmail.com> <20121005195836.GA94...@snakebite.org>
In-Reply-To: <20121005195836.GA94...@snakebite.org>
Cc: Python <python-l...@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1912.1349563535.27098.python-l...@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 12-10-05 12:58 PM, Trent Nelson wrote:
> I like them.  In particular, I like that I can enumerate all the
> subclasses that happen to implement the ABC via the metaclass's
> __subclasses__() method.
As long as you have a common base class (which in your case is a 
requirement), then __subclasses__ works for introspecting child classes. 
It doesn't *really* have anything to do with abcs.

> I also like that I can trust Python
> not to instantiate a subclass of an ABC unless it meets all the
> interface criteria I've stipulated.
Another way to read this is that you don't trust those using your code 
to be bright enough to understand what your code is doing and what it 
requires. In my mind, this seems to somewhat contradict the philosophy 
of "we're all consenting adults here". Whether you utilize interfaces or 
not, code should be documented. Your documentation would be responsible 
for laying out the expected interface (again, whether you're using the 
interfaces or not). Code would fail at some point if a requirement on an 
interface hasn't been filled. The *one* nice thing is that it'll error 
on import rather than execution time, but to me, if your code is unit 
tested, then all these things should be caught almost immediately anyway.

 From my experience (again, *only* talking about Python here), it seem 
to me that less is generally more. Less code means less things to read 
and tie together, making it easier to grok overall (not to mention less 
overhead for the interpreter, but that's virtually moot due to the 
*very* little overhead in 99% of cases of uses features such as abcs). 
Using abcs not only lends itself to code bloat, but it also leads to 
over-engineering as once you fall into old OOP habits, you start getting 
back to un-Pythonic code (pretty subjective statement, I know :)).


Again, please don't misunderstand my intentions here. I'm not arguing 
the need for abstract base classes in a strict OOP world. I'm arguing 
them as not genuinely being Pythonic.


Thanks for your the feedback so far.

-- 
Demian Brecht
@demianbrecht
http://demianbrecht.github.com