Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.python
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Are ABCs an anti-pattern?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Demian Brecht  
View profile  
 More options Oct 6 2012, 6:45 pm
Newsgroups: comp.lang.python
From: Demian Brecht <demianbre...@gmail.com>
Date: Sat, 06 Oct 2012 15:45:23 -0700
Local: Sat, Oct 6 2012 6:45 pm
Subject: Re: Are ABCs an anti-pattern?
Print | View thread | Show original | Report this message | Find messages by this author
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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google