Le samedi 25 novembre 2006 à 21:32 +0200, tomer filiba a écrit : > "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.
You can simply call it a behaviour rather than a contract. Contract-based programming is usually defined as involving pre- and post-conditions on method calls, to check that the method behaves as expected. The underlying idea is that the terms of the contract are programmatically enforced rather than simply declared. Wikipedia mentions those attempts at contract-based programming with Python: http://www.nongnu.org/pydbc/ http://www.wayforward.net/pycontract/ http://www.targeted.org/python/recipes/ipdbc.py > 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 Other suggestion: from MinimalSet def __contains__(self): pass The "origin" of the method is then clearly visible instead of being relegated at the end of the declaration (it works better with multi-line declarations too). Also the class declaration look nicer when you have several of these methods: class BazContainer: # Implement methods from MinimalSet from MinimalSet def __contains__(self): pass from MinimalSet def add(self): pass from MinimalSet def remove(self): pass # Other methods def to_bicycle(self): """ Turn this container into a bicycle """ (etc.) _______________________________________________ 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