On Thu, Jul 29, 2010 at 3:49 PM, Antoine Pitrou firstname.lastname@example.org wrote:
Le jeudi 29 juillet 2010 à 15:42 +0200, Tarek Ziadé a écrit :
On Thu, Jul 29, 2010 at 3:34 PM, Antoine Pitrou email@example.com wrote:
On Thu, 29 Jul 2010 15:25:20 +0200 Tarek Ziadé firstname.lastname@example.org wrote:
That makes sense. OTHO, if we drop the idea of having a __magical__ method, we could have an collections' ABC instead, called JSONSerializable, with one method to override,
This is more about declaring the interface rather than adding yet another __magic__ method
That's a nice OOP pattern to have imho
Python is supposed to be duck-typed. It would be strange to add a couple of random exceptions to that general rule. Moreover, having to *both* derive an existing class and implement the single method defined on that class is one complication too many.
Not sure to follow here, since ABCs are about having an object supporting a series of methods no matter what are the parent classes. e.g. this is closer to the concept of "interfaces".
IOW you don't need to derive from a parent class, you just to need to provide a given set of methods, and ABC provides a ways to check that an object has that signature.
Ok, but then how does it avoid having a __magic__ method? You can't use a normal name such as "to_json" because then an existing class with that method could be wrongly inferred as implementing your new ABC, and break existing code.
yes that's a possible side-effect, unless we explicitely register those class Using ABC's register technique.
Besides, defining an ABC for a single, module-specific method sounds rather overkill. This reminds of me of projects plagued by an overuse of interfaces for every possible concept.
Thats what Iterator did in ABC though.