David Abrahams <dave@boost-consulting.com>: > This concern seems most un-pythonic to my eye, since there are already > all kinds of ways any module can change the behavior of any call in > another module. Yes, but most of the time you don't have to use them! With this feature, it would be the *normal* way of using it. > forcing all the definitions to be in one place prevents an important > (you might even say the most important) use case: the author of a new > type should be able to provide a a multimethod implementation > corresponding to that type. You can get that without the notion of a generic function as a separate entity. Just have a dispatch mechanism that looks in all the arguments of a call for a method to use, instead of just the first one. That would be relatively tractable, since at least you'd know that the method must be found in one of the argument classes somewhere. It also doesn't suffer from the who-imports-the-module problem, since someone must have imported it in order to get an object of that class in the first place. The use case that this doesn't cover is where you're not defining a new class, just trying to add behaviour to handle a previously unanticipated combination of existing classes. The organisational problems involved in that aren't unique to Python, and seem to me an inherent feature of the problem itself. Where does functionality belong that isn't owned by any class? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4