<div><span class="gmail_quote">On 4/25/07, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I'm confused. Can you show a simple example of something that can be<br>checked at definition time? </blockquote>
<div> </div>
<div>Sure. Below is a slightly modified example from the doctest:</div>
<div> </div>
<div>>>> class AbstractCar(AbstractBaseClass): # inherit from AbstractBaseClass to make something abstract<br>... @Abstract<br>... def Drive(self,x): pass</div>
<div> </div>
<div>To make a class abstract, you inherit from AbstractBaseClass in order to get the metaclass set properly and then use a function decorator to declare methods abstract. This is similar to the proposed implementation in your
abc.py and equally pythonic or unpythonic. The following shows what happens when you define a class that doesn't override the abstract methods:</div>
<div> </div>
<div>>>> try: # illustrate what happens when you don't implement @Abstract methods<br>... class fails(AbstractCar): # an erroneous implementation of AbstractCar<br>... pass <br>... except AssertionError, e: # doctest: +ELLIPSIS
<br>... print e<br>Class <class '...fails'> must override Drive to implement:<br>[<class '...AbstractCar'>].<br> </div>
<div>The exception gets raised at definition time because the __call__ method of the metaclass inherited from AbstractBaseClass checks whether abstract methods have been implemented. In your implementation, you use the __new__ method of the metaclass to do the check at instantiation. If desired you could enable/disable checking at definition and instantiation separately.
</div>
<div> </div>
<div>A slightly tricky point is that if something inherits DIRECTLY from AbstractBaseClass (e.g., AbstractCar) then it is allowed to have abstract methods that have not been overridden. This allows you to define a partial abstraction as shown below:
</div>
<div> </div>
<div>>>> class AbstractFastCar(AbstractCar,AbstractBaseClass):# inherit from ABC<br>... @Abstract # so that interpreter<br>... def DriveFast(self): pass # doesn't worry about
<br>... # Drive being abstract<br> </div>
<div>My implementation will consider this a valid definition because AbstractFastCar inherits DIRECTLY from AbstractBaseClass and is therefore allowed to have abstract methods that have not been overridden. In an earlier post you claimed that my implementation forces you to declare a class abstract redundantly (and therefore unpythonic-ly) when this should be inferred from the class having abstract methods. I believe you were referring to the partially abstract class example above. I agree that this is redundant and unpythonic, but I believe this could be fixed by having the metaclass __call__ method check whether the class itself defines any abstract methods so you wouldn't need partial abstractions which define abstract methods to still inherit from AbstractBaseClass directly.
</div>
<div> </div>
<div>So far I believe that the main reasonable objection raised to definition time checks is in how the following example would be handled:</div>
<div> </div>
<div>>>> # Define a class that provides a helper function but is still</div>
<div>>>> # abstract in the sense that children must implement Drive.</div>
<div>>>> class AbstractCarHelper(AbstractCar,AbstractBaseClass): </div>
<div>... def DriveHelper(self):</div>
<div>... print 'Vroom!'</div>
<div> </div>
<div>The example above has no abstract methods, but if you want to make this kind of partial abstraction a legal definition you need to tell the interpreter that this is still an abstract class by inheriting directly from AbstractBaseClass. If we want def time checking, I don't see a way to make the above definition legal without somehow telling the interpreter to allow it to be abstract. I don't think this is unpythonic since inheriting from AbstractBaseClass is non-redundant. In fact, one could argue that it is good since it lets the programmer that AbstractCarHelper is still an abstract class even though it does not directly define any abstract methods.
</div>
<div> </div>
<div>If you ignore the last example, I don't think having def time checks for ABC enforcement has any disadvantages. You can easily turn off the def time checking or have it off by default and turn it on if desired. Since def time checks are done by __call__ and instantiation checks are done by __new__, this shouldn't interfere with anything in the original ABC PEP. So in my mind, the only reason to object to def time checks is if it bothers you that the last example must inherit directly from AbstractBaseClass.
</div>
<div><br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Using the machinery currently in the PEP,<br>any class that inherits an abstract method and doesn't override it is
<br>automatically an abstract class itself. There's nothing to complain<br>about at definition time.</blockquote>
<div> </div>
<div>Yes, I see that. What I'm proposing is to have __call__ in the metaclass complain if a class does not inherit directly from AbstractBaseClass and does not have any abstract methods. </div>
<div> </div>
<div>From your point of view, if you have def time checks turned off by default then the difference in using my proposal vs. the original ABC proposal all comes from the last example. For example, your Iterator class in
abc.py inherits from Iterable (which is abstract) and declares its own abstract method. Under my current implementation this would raise an error unless Iterator also inherits from AbstractBaseClass. This is easily fixable by having my implementation allow classes which declare their own abstract methods to be abstract. The incompatibly I pointed out in my last example is illustrated by the Set class in your
abc.py. I believe that you want Set to be an ABC which requires children to support the ABC requirements of its parents while providing useful implementations of __le__, __lt__, and __eq__. In my implementation you would need to have Set either inherit directly from AbstractBaseClass or define at least one abstract method to prevent an error at def time (if def time checks are on at all). Note that I don't think it would be unpythonic to have Set inherit from AbstractBaseClass since it provides someone reading the source code with the useful information that this is an ABC and not a concrete implementation.
</div>
<div> </div>
<div>In summary, let me try to clarify what I see as the only incompatibility between the current PEP and an ABC implementation: with def time checks turned on you would need partial abstractions like Set to somehow indicate that they are abstract by either inheriting directly from AbstractBaseClass or defining at least one abstract method. If people don't like that, then I don't have any response. But if people are worried about B&D and other things, I think those are non-issues. B&D at runtime is no better than B&D at def time (I think B&D at runtime is worse).
</div>
<div> </div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Your example implementation was a bit too much code for me to read.<br>:-) </blockquote>
<div> </div>
<div>No problem. Unfortunately, I think I might have made the example usage in this post a little too long to read (but hopefully not). :)</div>
<div> </div>
<div>-Emin</div>