Status of optional static typing in Python?

[George Sakkis]

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