Static typing

[Michael Muller]

Is there currently any plan to introduce static typing in any future
version of Python? (I'm not entirely sure that "static typing" is the right
term: what I'm talking about is the declaration of types for variables,
parameters and function return values).

I know there was a "types SIG" which introduced several proposals, but it
expired quite a while ago, and I was wondering whether whether some
consensus has been reached on the subject or if it has just been shelved
indefinitely.

 

[Bruno Desthuilliers]

Is there currently any plan to introduce static typing in any future
version of Python?

AARGGHHHH ! NO !! DON'T DO THAT !!! NEVER AGAIN !!!!

(sorry, uncontrolable nervous reaction... 3 valiums latter... : )

(I'm not entirely sure that "static typing" is the right

term: what I'm talking about is the declaration of types for variables,
parameters and function return values).

This is the right term. This is also the wrong thing for Python IMHO.

I know there was a "types SIG" which introduced several proposals, but it
expired quite a while ago, and I was wondering whether whether some
consensus has been reached on the subject

<flame-war-mode='on'>
Yes :
dynamic typing is good a Good Thing(tm),
static typing is Evil(tm) !-)
</flame-war-mode>


Bruno

 

[Bruno Desthuilliers]

Is there currently any plan to introduce static typing in any future
version of Python?

Seriously, why would you do that ?

Bruno

 

[Aahz]

Well, here's a pattern I've been trying out for this purpose: use assert
statements at the top of the function.

def foo(bar, baz):
assert isinstance(bar, int)
assert isinstance(baz, str)

I'm quite happy with the pattern, although there are a couple of
negative points that I can think of:

- It's a bit verbose, although that verbosity enables you to perform
bounds checking and operate with other type systems like Zope's interfaces.

- You can't specify the type of the return values this way.

You skipped the crucial negative: it breaks Python's name-based
polymorphism. If someone creates a class that works just like a string
but doesn't derive from the str class, your program breaks for no good
reason.

 

[Neil Hodgson]

Shane Hathaway:

Well, here's a pattern I've been trying out for this purpose: use assert
statements at the top of the function.

def foo(bar, baz):
assert isinstance(bar, int)
assert isinstance(baz, str)

The Wing IDE will read assertions of the above form and provide more
assistance than with identifiers it knows nothing about:
http://wingide.com/psupport/wingide-1.1/node5.html#SECTION005800000000000000
00

Neil

 

[Shane Hathaway]

Shane Hathaway:




The Wing IDE will read assertions of the above form and provide more
assistance than with identifiers it knows nothing about:
http://wingide.com/psupport/wingide-1.1/node5.html#SECTION00580000000000000000

Excellent. It's nice to have an idea validated.

Shane

 

[Scott David Daniels]

Seriously, why would you do that ?

You _might_ want some static typing information as program
documentation or to enable efficient program translation. The
types sig was interested in allowing type annotation where
possible. Remember, the type you might want may be more like
"what protocol must these objects (the ones passing through
this variable) follow" than "what are the construction details
of these objects".

I would like to see interface descriptions describing what
kinds of parameters are required and results produced for
packages that I am considering using. If there were a single
central-python-endorsed form for those descriptions even better.
If the descriptions can be mechanically read, and at least
sometimes mechincally checked (possibly slowly, possibly only
for slow execution), I might use such a system to check a module
before announcing it to the world.

A very old Sun study determined that most variables in a
dynamically typed system (smalltalk, IIRC) are almost always
of the same type.

David Ungar got a fair amount of mileage out of optimizing for
a guessed common case in a protype-driven language where you
couldn't even name types in the language (you make objects
"just like that one except...").

I had a sketch of how to optimize for OODBs using behavior-based
typing. The big trick was to use the DB's knowledge of the classes
in the DB (provided for each instance in the DB) to determine
when there was, at least currently, only one method for the given
function. An environment like that might be able to do much
better at query optimization than any OODB that allows you to
store arbitrary objects and retrieve them based on message calls.

-Scott David Daniels
(e-mail address removed)

 

[Bruno Desthuilliers]

Well, it appears that I have inadvertantly trolled c.l.p. I humbly
apologize. I really just wanted to know what the status of the issue
was.

I may be wrong, but I don't think anyone took your question as a troll -
well, I didn't anyway.

FWIW, I do favor the addition of optional static typing for the two
reasons Scott described - interface documentation and optimization.

Interface documentation may be obtained in others ways (docstring for
exemple). And I'm not sure static typing would optimize anything, but
not being a Python (nor anything else) guru, I would not bet my hand on
this...

my 2 cents...

Bruno

 

[Tayss]

Interface documentation may be obtained in others ways (docstring for
exemple).

Indeed! As I remember, Jython uses doc strings for typing, when it
presents an API to Java. So it's in the comments, and I think that's
an oddly appropriate place for hints to the compiler.

And I'm not sure static typing would optimize anything, but
not being a Python (nor anything else) guru, I would not bet my hand on
this...

If you mess around with lisp, you can easily see the compiled assembly
language of your functions when you experiment with optional typing.
(By calling the function "disassemble".) Normally, the compiler spews
a lot of general code because it doesn't know what you've passed in.
But when you promise that you're passing in numbers or something, the
assembly language is much tighter.

Sort of like when someone asks you to move something to a different
house, and you have no idea how big it is. If you were told, "It's
just a pillow," you know that you don't need to order a huge truck or
take any special precautions.

 

[Bruno Desthuilliers]

Yes, and that's the way that I do it now. But the problem with this is
that it's "non-binding": it doesn't impose any programmatic constraints.
Because of this:

- it's hard to enforce automatically (if you want to make sure that all
programmers in your team are using the prescribed argument definition
conventions, you have to parse all the docstrings)

It's a management problem, not a programming language issue.

- there is no global standard (I might use "name: type info" in my
docstring, you might use "type name")
Idem.

- it is hard to guarantee that the documentation is in sync with the code
(if you change the type expectations of a function, you can do so without
changing the documented expectations)

Idem. If your programmers don't care about keeping doc in sync, you're
in trouble whatever the language.

- it makes type errors less obvious (you end up getting an attribute
error when you perform an operation on the value instead of a type error
when you initially abuse the interface) Although, I must say that this is
surprisingly less of a problem in Python than one might expect.

Yep. Type errors are not the most common nor the most annoying bugs. If
only declaring types three times was enough to get bug-free programs...

In and of itself, static typing does not optimize anything. In fact, it
could slow things down because you suddenly have to do typechecks all over
the place.

Static typing can be /used/ for optimizations because it allows for
optimized forms of attribute access -
Right.

without it you must do dynamic name
resolution at runtime.

Which is a Good Thing IMHO.

For example, if you want to resolve a method name, you currently have to
look up the method name in the object and its classes. With static
typing, since you know the type of the object at compile time, you can
just reference it in a "vtable" (a virtual function table) associated with
the object.

In short, static typing brings us one step closer to "python compiled to
machine code".

Well... Objective C is compiled to machine code, and still has dynamic
binding (not late binding as in C++), so static typing does not seem
mandatory here.

Anyway, I personnally don't have a compelling need for Python being
compiled into machine code, and just don't want to here about it if it
implies static typing !-)

The only thing that could make sens to me would be a protocol-checking
mechanism, and there are already some.

Bruno

 

[Colin J. Williams]

Seriously, why would you do that ?

You _might_ want some static typing information as program
documentation or to enable efficient program translation. The
types sig was interested in allowing type annotation where
possible. Remember, the type you might want may be more like
"what protocol must these objects (the ones passing through
this variable) follow" than "what are the construction details
of these objects".

I would like to see interface descriptions describing what
kinds of parameters are required and results produced for
packages that I am considering using. If there were a single
central-python-endorsed form for those descriptions even better.
If the descriptions can be mechanically read, and at least
sometimes mechincally checked (possibly slowly, possibly only
for slow execution), I might use such a system to check a module
before announcing it to the world.
[and some other things]

It would be helpful to have some sort of consensus as to what form
these descriptions should take.

As suggested, it's desirable that description be both human and
machine readable. I would suggest that priority be given to
the former.

Colin W.

 

[Greg Ewing (using news.cis.dfn.de)]

Sort of like when someone asks you to move something to a different
house, and you have no idea how big it is. If you were told, "It's
just a pillow," you know that you don't need to order a huge truck or
take any special precautions.

But in Python, you wouldn't have to move the object
itself to the new house, only a reference to it!

Of course, if it's a mutable pillow, it might not
be a good idea to have two people sleeping on it at
the same time, in which case you'd want to make a
copy.

 

[Michael Muller]

It's a management problem, not a programming language issue.

Well, I really don't care to argue the issue, but I will say that I
personally prefer a technical solution (e.g. static types) to a management
solution (e.g. me reading everybody's code and smacking them with a
Big Stick(tm) when they don't comply).

Well... Objective C is compiled to machine code, and still has dynamic
binding (not late binding as in C++), so static typing does not seem
mandatory here.

For the record, Objective C has the same problem. If you look through
the library, method resolution is implemented using a runtime lookup.
It's basically C with an embedded interpreter.