On Thu, 2006-03-30 at 12:05 +1200, Greg Ewing wrote: > Adam DePrince wrote: > > > SetView implements: > > .__contains__ > > .add > > .discard > > .__len__ > > But what would there be to inherit from the mixin? > Each view class will have entirely its own implementation > of these, depending on the details of the base object. > Inheritance in Python is *entirely* about implementation > inheritance, not interface inheritance. > > > By allowing dict.keys() to announce "I'm a SetView" > > If you mean to make it possible for code to do > > if isinstance(something, SetView): > ... > > that's another thing that Python tries to stay away > from as much as possible. > > If what you're proposing is purely a conceptual > classification, I still think it's far too > elaborate. Anyone reading such a specification is > going to have their eyes glaze over within a few > milliseconds.
Only if they examine Python from the perspective of Python ... from a C-api perspective there are certain advantages to lumping things into interfaces, and in the C-API there is no inheritance. The manifestation of these interfaces would be in the naming convention ... __len__ would become part of the View (note the PEP changed since the above SetView implementation description) interface and called PyView_len. I'm trying to address both perspectives here; the user is free to toss these interfaces and code just knowing what methods to provide trusting that everything will quack right. > > -- > Greg > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/adam.deprince%40gmail.com _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
