What If..... Strong Types

[brueckd at tbye.com]

On Sun, 16 Jun 2002, Don Garrett wrote:

>    Primarily, what if classes always had rigidly defined interfaces. I
> mean that public members had to be declared to exist, and that methods
> couldn't be modified on an instance. Private members could exist but
> would be really private.

:( IMO this would add little value and we would lose a lot in the process. 
I wouldn't be bothered if some sort of optional interface support was 
built into the language itself, but I don't have the problem with the lack 
of it today (same with private members - it just doesn't cause me any 
problems the way it is). On the downside, some of the most Pythonic 
solutions to problems that'd be messy to solve in other languages are 
quite elegant in Python because of its "dynamicness". For example, it's 
sooo convenient to attach/detach members to objects as they pass through a 
program's workflow. Having to declare them all up front or whatever would 
be messy.

> All types would be classes (including ints and such).

I never understood all the hooplah over ints not being classes. I've only 
ever seen a handful of cases where it might be useful, and lots of cases 
where it'd get abused, but some people really seem to want it.

>    My belief is that almost all the convenience of Python would be
> maintained, but that compilation, optimization, and automated code
> analysis would be simpler.

I'm _sort of_ in favor of some optional type annotation for optimization 
purposes, and sort of against it, the idea being that after your code is 
done you could go back and annotate (or even have a tool suggest 
annotation) variables with type information such that you are saying that 
a particular variable name will always refer to integers, for example. My 
fear, though, is that it would be used too often, i.e. people would 
provide type information in places where it wouldn't help at all in terms 
of execution speed. One of the beauties of Python is the clean syntax, the 
readable code. A good portion of that is the code is not encumbered with 
all sorts of variable and type declarations. I like the approach of Pyrex 
because it's close to Python but still separate enough to prevent people 
from using it too much - if you make it too easy to optimize the code then 
people will optimize it too often. Bleh.

>    I'm just wondering if the change would be good or bad. Would it really 
> break anything important in Python today?

You might not consider it important, but it'd break a lot of _my_ code, so 
it'd be important to me! :) Python doesn't force you to use all its 
dynamic abilities, but I regard that as one of the tools of the Python 
toolbox, so yes, I'd be hurt by its removal.

> Would it prevent any common errors? 

It'd be most useful for people who skimp on testing, but the added 
complexity might actually introduce errors, so who knows what the net 
effect would be - perhaps even buggier code than without it.

> Would it help with automated code analysis (compilation and optimization 
> included) as much as I think it would?

Dunno - how much do you think it would? ;-) A better question, is how
often do we really need compilation and optmization at all anyway? If it's
less than 10% (which I believe it is), then the payoff generally wouldn't
be worth language-wide changes. A plain extension module (especially with
the help of Boost, SWIG, PyInline, etc.) isn't too painful, and projects
like Pyrex might have a permanent niche too, but in all cases they are one 
step removed from standard Python - which is exactly where they belong.

-Dave