Christian Convey wrote: > Perhaps I'm deluded but I don't think so. I'll tell you my situation > and I'd appreciate your take on it... > > I'm looking into the design a network simulator. The simulator has a > few requirements: > > (1) I need to be able to swap in a variety of replacement components > during different simulations. I.e., RadioFrequencyChannelModel, > WiredNetworkChannelModel, etc. This drives me to want the notion of > inherited interfaces, partly as a form of documentation. > > (2) I want a form of encapsulation (which I realize isn't necessarily > guaranteed in all possible static typing implementations). I.e., I want > to ensure that any code which accesses a ChannelModel only calls those > methods that are part of the ChannelModel interface. If there's a > method RadioFrequencyChannelModel.setBroadcastDistance(...), which isn't > part of the generic ChannelModel interface, I don't want most of my code > to be able to start using that particular method, if the code need to be > able to work with all possible ChannelModel implementations. > > (3) I like Interfaces as a matter of documentation. It helps me to > thing things through. I've got a lot of components that must support > interchangeable implementations: channels, modems, MAC layers, link > layers, etc. If I have an abstract MAC_layer interface, it helps me > think carefully about what every MAC layer ought to provide, and it also > helps me explain to other people what a MAC layer in my simulator must > provide. That is, it helps me better explain to other people how the > system's major components relate to each other.
All your concerns (and several more) have been beaten to death in past topics about the benefits and shortcomings of static typing, you can look them up. Briefly, python doesn't prevent you from writing good documentation and have nice, clean interfaces if you want to, and indeed there are several Interface implementations around. Still it doesn't force you to do so like other "pure" OO languages, which is very handy if you don't have a crystal clear idea of how your interfaces should be laid out in advance or if the requirements change along the way, both very typical scenaria in the real world. As for encapsulation, again the idea is convention rather than language enforcement. The convention is to have all non-public elements (attributes, methods, functions, classes, etc.) starting with a single underscore. A client can still access it, but he takes the responsibility of relying on an implementation feature, which is typically less stable than the public interface. > Now, I could use Java or C# to get functionality such as interfaces, but > I loath giving up the general productive goodness of Python. That's why > I'm looking for something like interfaces. Others have already mentioned some Interface add-on packages that you can download and use right away; another option you may want to look into is the type-checking module (http://oakwinter.com/code/typecheck/). > But even if we disagree about the wisdom of my intentions, do you know > if/when Guido's planning to work that stuff into Python? The last post > I noticed from him on the topic was from 2005. At least back then he > sounded pretty into it. I wouldn't count on it if I was to start a project sometime soon. George -- http://mail.python.org/mailman/listinfo/python-list
