on 12/7/2006 11:25 AM Bill Janssen wrote: >> To me, even if Car happens to represent a dict by being able to be used >> as a dict, the expression of this fact feels better expressed as merely >> implementing dict. >> >> compare: >> >> class Car(dict): # car... is a dict? hmm, a bad ring to it >> ... >> >> class Car: >> implements dict # oh, Cars can be used like a dict, got it >> ... > > OK, I guess the difference is that, for me, (1) this doesn't happen a > lot (ever?), and (2) I don't feel that the nuance here is important > enough to add another mechanism to the language which needs to be > supported. I'd rather just use type inheritance.
I'm neither surprised nor do I frown upon your preferences. I'm just letting you know that I look at python in a different way than you do. The intent of the sketch is to bring together different camps of pythonists by presenting a framework that recognizes those that would use python in different ways. > >> Without something like an implements declaration, if I ever >> want to express a relationship to another class, but with different >> internals, I am forced to first define an abstract class and then >> inherit from that. With an implements declaration, I can say implements >> dict and be free of inheriting any of its internal implementation. > > That's why it's important for Python to have a clear set of base > interface types for people to use. Here, we are focused on base types. I like what ABCs are going to allow. And I've incorporated ABC's into some of the syntax examples. As a note, I'll repeat the point I made last post. As a regular python user, I'm well acquainted with dict. But, looking at the ABC page right now, to implement Dict, I'll need to inherit Mapping and MutableContainer. If is that Dict is an abstract class itself and dict is a concrete implementation of Dict, then I again bring up the benefit of being able to say something like "implements dict" versus class A(Dict) while in my head I'm thinking: I want A to be used just like dict. This example is coming from the ABC context of things. I'd expect, with just an inheritance-based solution, a lot of user code out there would have to deal with the same Interface/well-known class dilemma as well, where they would have a core set of classes that they'd feel obligated to copy into interfaces, just so third party code could easily inter-operate with their code-base. > >> In the syntax sketch, an Implementation is basically a list of >> types/class, methods, and other Implementation lists. > > That sounds a whole lot like a Python 2.5 class, to me. I'm surprised that your understanding of what an Implementation (as defined in the syntax sketch) is doesn't seem to be what I'm thinking of. Also, I'm not sure I understand what you mean by it sounding like a Python 2.5 class. Please explain further. > > Bill _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
