i'd suggest using the term "contract" instead of abilities or interfaces. they way BDFL described it [1], abilities specify more than mere method signatures -- they go as deep as how the implementation should implement the desired behavior.
http://mail.python.org/pipermail/python-3000/2006-November/004782.html > I'd start by defining three abilities: MinimalSet which only provides > the 'in' operator; IterableSet which also provides iteration (but not > len(); it may aply to infinite sets); and StandardSet which adds most > standard operations on sets [...] > If a class claims to be a set, it should conform > to a much richer contract, which guarantees the basic properties of > mathematical sets. For example, a&b == b&a, a&a == a, and so on. "contract" is a better term, IMO, since it's already used in CS (as in Eiffel), and describes the situation more correctly: *behavior* rather than *signature*. "ability" just doesn't seem right to me: my class is not *able* to be a set, it *behaves* like a set. it follows the set contract, not "ability" - - - - - instead of the suggested /defop/ keyword, which seems very awkward to me, i'd prefer an extension to the current function syntax: def __contains__(self) of MinimalSet: pass if we don't want to make "of" a keyword, we can use "in", with a similar meaning. this syntax is inspired by (god forbid) visual basic .net: http://msdn2.microsoft.com/en-us/library/sect4ck6.aspx Class Spam Implements IFooable Sub Foo(ByVal x as Integer) As String Implements IFooable.SomeMethod ... End Sub End Class the suggested syntax of defop MinimalSet::__contains___(self, other): pass starts to look like C++ to me (yuch), and it's not necessarily an "operator", as *defop* implies. -tomer _______________________________________________ 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
