[meta-sig] [Types-SIG] Python vs. Smalltalk/Strongtalk, etc. Was: The Types-
SIG is comatose.
Fri, 3 Dec 1999 10:03:04 -0800
Paul Prescod wrote:
> And let's start with a clear direction from the Powers that Be.
> I propose:
> * the goal is a optional static type system for version 2.
> * presume that the type/class dichotomy has been removed in V2
> * backwards compatibility with current code is relatively important
> * compatibility with the Python 1.x interpreter is NOT important
> * interfaces are not an issue
> * parameterized (template) types are not available
> * names are type checked, not expressions
> * got now, only named types (types and classes) can be declared, not
> lists and tuples of types
There are a lot of different proposals. Do we all agree on all of these
> Start from these (very similar!) proposals:
> The current Visual Basic type system
> Something somewhere from JimH
> The type declaration part of strongtalk
> The first half of this:
It must be serendipity, but I was just thinking about this subject
yesterday, and I went so far as to look up Strongtalk and download Squeak.
Syntax differences aside, what I think we would benefit from is a comparison
of the capabilities of Python1.x and proposed Python2 to
Smalltalk/Strongtalk/Squeak, Visual Basic, etc. For me, I am looking at
Python as a general purpose language, rather than a scripting language, so
programming-in-the-large features are important.
-- Specific questions: --
What if the C definition of functions and methods were extended by adding a
signature object? (If so, how can signatures be specified?) Could the
signatures then be used to generate more efficient code? Should there be
function/method choice by signature?
Maybe I'm trying to make Python into something it wasn't intended to be, but
I have this wish that I wouldn't have to use different languages for
Howard B. Golden
Litton Industries, Inc.
Woodland Hills, California