I disagree. I think that B&amp;D-ish enforcement of ABCs is the most important feature of an ABC (with the option of being able to turn off enforcement on a per-class basis). <br><br>Imagine you have a program that takes a long time to run. If you use duck-typing or similar ideas you may watch the program run for hours or days and then raise an AttributeError or NotImplemented error because a derived class didn&#39;t implement a required method. With B&amp;D-ish enforcement of ABCs, you can automatically catch such problems as soon as the program starts. This is a problem that I see no other good solution to. For long running programs, unit-tests will also take a long time to run so the argument that your unit-tests should catch such errors is no longer valid. Also, while pylint and pychecker are great tools that could be used to catch such errors, they must be run manually by the programmer and generally take a long time to run (at least longer than the ABC implementation I have).
<br>&nbsp; <br>To reiterate, while I think the documentation and reflection benefits of ABCs are nice, I don&#39;t think they are nearly as essential as enforcement. For most of the use cases I&#39;ve seen, you could just as easily read the documentation or the source code or try a simple example to determine how to implement an iterable or hashable that will play nice with other classes. In contrast, ABC enforcement provides the real benefit of catching errors before many hours of program runtime are wasted. Consequently, I&#39;m +1 on B&amp;D in this case.
<br><br>-Emin Martinian<br><br><div><span class="gmail_quote">On 4/25/07, <b class="gmail_sendername">Paul Moore</b> &lt;<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 25/04/07, Greg Ewing &lt;<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>&gt; wrote:<br>&gt; Do we really need to have B&amp;D-ish enforcement of abstract<br>&gt; method implementation? It doesn&#39;t seem pythonic to me.
<br>&gt; I might want to leave some methods of an ABC unimplemented<br>&gt; because I&#39;m not intending to use them. I&#39;d be annoyed if<br>&gt; I were prevented from doing that because of some theoretical<br>&gt; notion that they &quot;should&quot; be implemented.
<br><br>I agree - this whole discussion still sounds like things are getting<br>overly strict.<br><br>OTOH, in Greg&#39;s case maybe he should just not bother inheriting from<br>the ABC. From what I hear, that shouldn&#39;t cause him any problems
<br>(&quot;duck typing isn&#39;t going away&quot; is the message I&#39;ve heard). Of course,<br>it&#39;s difficult to be sure without specific examples (on either side of<br>the debate).<br><br>Paul.<br>_______________________________________________
<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">http://mail.python.org/mailman/listinfo/python-3000</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/emin.shopper%40gmail.com">http://mail.python.org/mailman/options/python-3000/emin.shopper%40gmail.com</a><br></blockquote></div><br>