> Actually, I don't find it particularly appealing myself. The PEP > specifically states that it isn't intended to replace duck typing, so > I'm having trouble understanding the rationale in the first place. I > just wanted to make sure I knew now if there was any plan to support > them in the near future, so I could mention it in my book if > necessary, while I still have half a chance.
I think a major motivation for ABCs is as stated in the PEP, "Much of the thinking that went into the proposal is not about the specific mechanism of ABCs, as contrasted with Interfaces or Generic Functions (GFs), but about clarifying philosophical issues like "what makes a set", "what makes a mapping" and "what makes a sequence"." If you approach the ABCs purpose in Python 2.6 as an improvement to documentation and specification, and disregard the mechanisms of ABCs (e.g. isinstance() checks are overloaded and sub-class instantiation is prevented if abstract methods are not supplied by concrete methods) then the line of thinking: "ABCs aren't intended to replace duck typing" would also suggest the statement that "Sphinx-generated Python documentation isn't intended to replace duck typing." Of course, the later is fairly silly - no one has accused Sphinx of "bringing static typing to Python" :P However, the primary motivation behind interfaces and ABCs has been to improve documentation - by making the documentation more formal and specific. With the thinking of :ABCs-as-documentation", one can benefit from ABCs in Django without needing to actually use the Python 2.6+ standard library or have backwards-compatible imports. Instead, look at Sequences, Mappings and Sets that are defined already in Django and compare their interfaces to the ABC collections interfaces - if there are differences, then thinking about API changes might be warranted. For example, it might be beneficial to treat a QuerySet object as a specialization of Python's Set object. In this case one can look at the Set interface defined in the PEP and see that __xor__, __sub__, and __contains__ are missing from QuerySet objects - but perhaps these make sense to implement? At which point a Set object and a QuerySet object can be said to have the same API, which could be declared by: - inheriting from the Set class - registering the QuerySet class as a "virtual abstract base class" - Making a note somewhere in the documentation of the QuerySet class The benefit of the last approach is it is backwards compatible all the way back to Python 1.0 without requiring noisy, defensive imports. However that approach is "semi-formal" in that there is no way to programatically determine that an instance of a QuerySet and a Set both provide the same API. The other two approaches are more formalized, but ABCs perform magic with isinstance() checks, which can have the undesirable effect of allowing type-checking to be used when duck typing would be prefered for greater flexibility in the code. Then again you might find a use-case where you really do want to do type-checking but at least for people new to ABCs and Interfaces tend to add type-checks where not needed and make the code more rigid than it needs to be - at least that was my experience with my own code when learning to use Interfaces from the zope.interface package. On a side note, it's interesting that the discussion of Interfaces and ABCs in Python is now 10 years old! The original discussion on Interfaces and ABCs took place at IPC 8 in 1998 (and much of the historical discussions and debates on interfaces and ABCs are still relevant today): http://www.zope.org/Members/jim/PythonInterfaces/Summary And Guido's photo album from that conference (when many Pythonistas still had more full sets of hair!) http://www.python.org/~guido/confpix/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
