Status of optional static typing in Python?

[Christian Convey]

Hi guys,

I'm looking at developing a somewhat complex system, and I think some
static typing will help me keep limit my confusion. I.e.:

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Does anyone know if/when that feature may become part of Python?

Thanks very much,
Christian
--
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
[phone]
co******@npt.nu wc.navy.mil

[Bruno Desthuilliers]

Christian Convey a écrit :

Hi guys,

I'm looking at developing a somewhat complex system, and I think some
static typing will help me keep limit my confusion.

Then I think you're suffering from an alas too common delusion. Static
typing (at least declarative static typing) will only makes your system
more complex. But if you want some help in managing complexity, you may
want to look at interfaces systems (Zope3 interfaces or Peak's Protocol)
and multidispatch (Peak's Protocol dispatch package).

[Christian Convey]

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., RadioFrequencyC hannelModel,
WiredNetworkCha nnelModel, 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 RadioFrequencyC hannelModel.set BroadcastDistan ce(...), 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.
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.

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.

Thanks,
Christian

Bruno Desthuilliers wrote:

Christian Convey a écrit :

Hi guys,

I'm looking at developing a somewhat complex system, and I think some
static typing will help me keep limit my confusion.

Then I think you're suffering from an alas too common delusion. Static
typing (at least declarative static typing) will only makes your system
more complex. But if you want some help in managing complexity, you may
want to look at interfaces systems (Zope3 interfaces or Peak's Protocol)
and multidispatch (Peak's Protocol dispatch package).

--
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
[phone]
co******@npt.nu wc.navy.mil

[Kay Schluehr]

Christian Convey wrote:

Hi guys,

I'm looking at developing a somewhat complex system, and I think some
static typing will help me keep limit my confusion. I.e.:

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Does anyone know if/when that feature may become part of Python?

Thanks very much,
Christian

It was discussed recently at the Python 3000 mailing list and it seems
that the goals are not very ambitious but this was already clear from
Guidos Artima blog post you cited. So it may happen that type
annotation syntax in function signatures will be introduced in Py3K but
the semantics is reduced to a "protocol" i.e. Python will still be
untyped in a strict sense ( or dynamically type checked to put it more
positive ).

An proposed alternative for type annotation syntax and runtime
type-checks that comes up from time to time is using decorators for
this job.

Here is a recipe that might be usefull in your project right now:

http://aspn.activestate.com/ASPN/Coo.../Recipe/426123

Regards,
Kay

[Bruno Desthuilliers]

Christian Convey a écrit :

Perhaps I'm deluded but I don't think so.
<after what='having read the rest of the post'>.
You are.
</after>
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., RadioFrequencyC hannelModel,
WiredNetworkCha nnelModel, etc. This drives me to want the notion of
inherited interfaces, partly as a form of documentation.
Ok.
(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 RadioFrequencyC hannelModel.set BroadcastDistan ce(...), 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 .
This is mostly a self-discipline issue. But FWIW, unit-testing should be
enough here. And if you really want something more
bondage-and-discipline, you can use some wrapper object to filter out
the exposed interface. There's very few to do - here's a possible (while
mostly dumb) home-made solution:

class InterfaceType(t ype):
def __new__(meta, class_name, bases, new_attrs):
cls = type.__new__(me ta, class_name, bases, new_attrs)
cls._exposed = [name for name in new_attrs.keys( ) \
if not name.startswith ('_')]
return cls

class Interface(objec t):
__metatype__ = InterfaceType
@classmethod
def _expose(cls, name):
return name in cls._exposed

class InterfaceRestri ctor(object):
def __init__(self, obj, interface):
self._interface = interface
self._obj = obj
def __getattr__(sel f, name):
if self._interface ._expose(name):
return getattr(self._o bj, name)
else:
raise AttributeError( "name %s not allowed" % name)

And you can use a decorator specifying arg names or types -> expected
interface to automagically ensure you get correctly wrapped objects in
the client code.

NB : Don't use that code - here again, object-adaptation (which is at
the core of Zope3 interfaces and Peak's Protocols) comes to mind...
(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 :
BTW, did I suggest to have a look at Zope3 interface or Peak's protocols ?-)
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.
Ok, now this is a design issue. All you need here is an UML-aware
drawing program.
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.
Given your motivations and requirements (which seems pretty sensible
AFAIC), you definitively want to have a look at Zope3 Interfaces or Peak
Protocol. They'll give you *much* more than Java's interfaces.
But even if we disagree about the wisdom of my intentions,
We don't. The point on which we disagree is the proposed solution !-)
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 don't think this will ever make it into Python. But you really don't
need it anyway. Well, IMHO at least !-)

[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., RadioFrequencyC hannelModel,
WiredNetworkCha nnelModel, 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 RadioFrequencyC hannelModel.set BroadcastDistan ce(...), 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

[John Roth]

Christian Convey wrote:

Hi guys,

I'm looking at developing a somewhat complex system, and I think some
static typing will help me keep limit my confusion. I.e.:

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Does anyone know if/when that feature may become part of Python?
Optional static typing is listed as item # 3 in
PEP 3100 (Python 3.0 plans).
For a timeline, look at PEP 3000.

John Roth

Thanks very much,
Christian
--
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
[phone]
co******@npt.nu wc.navy.mil