Typing system vs. Java

Michael Abbott michael at rcp.co.uk
Tue Jul 31 10:08:22 EDT 2001


Peter Hansen <peter at engcorp.com> wrote in
news:3B66B3A2.F47BA3E2 at engcorp.com: 

> Michael Abbott wrote:
>> 
>> I for one would like to see a strongly typed variant of Python: if for
>> nothing else, I'd like to be able to compile my code. 
> 
> How would that let you compile your code?  Lack of compile-time
> type checking is hardly the only thing making it difficult to
> develop a Python compiler.

Hmm.  Well, it's interesting to look at the byte code interpreter source 
and to consider just how much time and effort is spent in working out what 
the types of operands are and therefore which particular operation to 
invoke.  You can't avoid that without static typing of some sort.


> More to the point, why would you want to compile your Python code?
> 
> If for packaging reasons, there are effective alternatives in
> the form of, for example, py2exe.
> 
> If for performance, the better approach is perhaps to profile your
> code, then rewrite the performance-critical portions as C 
> extensions.  Then you have pretty much the best of both worlds.

Possibly, possibly.  Perhaps I'm old fasioned, and too concerned about 
efficiency.  I know that processor speeds have increased by a factor of 
1,000 or so in the last couple of decades or so, but it gives me the creeps 
to see just how much code is executed to implement such simple expressions 
as 1+2 or f(x).  
    I'm concerned to write efficient and secure systems which handle high 
volumes of data reliably.  I believe that Python has three weaknesses, but 
unfortunately these weaknesses are also at the heart of its strength:

1.  No static type checking means that a very large class of errors 
(including undeclared identifier access) cannot be caught until run time.

2.  Efficient compilation is not possible, because operators and function 
calls cannot be compiled to anything simpler than the existing byte code 
interpreter's current interpretation.

3.  There is no data hiding.


>> Let me just observe this: statically typed Python would need to be a
>> different language from standard Python, though hopefully close enough
>> to interoperate and have the same name. 
> 
> It would be interesting, perhaps, to see how well such a beast
> would be adopted by the programming community.  I can just see
> the "marketing war" triggered as both sides try to promote
> their own version of Python as the One True Way to program...
> 

I think it's a pretty safe bet that most people prefer dynamic types.  
Writing statically typed code is harder.  I doubt that statically typed 
Python would be a competitor: I see it as more of a niche solution.

Also, it's pretty clear that the three weaknesses I've just complained 
about are simultaneously part of the strength of Python.

1.  No static type checking means that it is not necessary to work out a 
type description (which may be very complex) and it is easy to modify 
existing code to change its behaviour.  It also means, often, that when a 
type error does occur there can be useful run time information about the 
cause of that error.

2.  The edit and run cycle of Python is very slick and easy to use.  

3.  Of course, the lack of data hiding means that developers have more 
access to the internals of libraries, and there is no arguments about 
whether certain methods should be hidden or exposed.

Finally, it is possible to do some very clever things with the dynamically 
adaptive type structure of Python and it will be very difficult to capture 
many of these features in a strict static type system.



More information about the Python-list mailing list