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.

--
Remove the spam and filter components to get my e-mail address.

[Bruno Desthuilliers]

Re: Static typing

Michael Muller wrote:[color=blue]
> Is there currently any plan to introduce static typing in any future
> version of Python?[/color]

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[color=blue]
> term: what I'm talking about is the declaration of types for variables,
> parameters and function return values).[/color]

This is the right term. This is also the wrong thing for Python IMHO.
[color=blue]
> 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[/color]

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


Bruno

[Bruno Desthuilliers]

Re: Static typing

Michael Muller wrote:[color=blue]
> Is there currently any plan to introduce static typing in any future
> version of Python?[/color]

Seriously, why would you do that ?

Bruno

[Scott David Daniels]

Re: Static typing

Bruno Desthuilliers wrote:[color=blue]
> Michael Muller wrote:[color=green]
>> Is there currently any plan to introduce static typing in any future
>> version of Python?[/color]
> Seriously, why would you do that ?[/color]

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
Scott.Daniels@A cm.Org

[Aahz]

Re: Static typing

In article <mailman.105916 9958.20638.pyth on-list@python.org >,
Shane Hathaway <shane@zope.com > wrote:[color=blue]
>
>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.[/color]

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.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

[Neil Hodgson]

Re: Static typing

Shane Hathaway:
[color=blue]
> 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)[/color]

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]

Re: Static typing

On 07/25/2003 07:36 PM, Neil Hodgson wrote:[color=blue]
> Shane Hathaway:
>
>[color=green]
>>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)[/color]
>
>
> 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-...00000000000000[/color]

Excellent. It's nice to have an idea validated. :-)

Shane

[Bruno Desthuilliers]

Re: Static typing

Michael Muller wrote:[color=blue]
> 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.[/color]

I may be wrong, but I don't think anyone took your question as a troll -
well, I didn't anyway.
[color=blue]
> FWIW, I do favor the addition of optional static typing for the two
> reasons Scott described - interface documentation and optimization.[/color]

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]

Re: Static typing

Bruno Desthuilliers <bdesth.nospam@ removeme.free.f r> wrote in message news:<3f23ae06$ 0$21093$626a54c e@news.free.fr> ...[color=blue][color=green]
> > FWIW, I do favor the addition of optional static typing for the two
> > reasons Scott described - interface documentation and optimization.[/color]
>
> Interface documentation may be obtained in others ways (docstring for
> exemple).[/color]

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.

[color=blue]
> 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...[/color]

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 "disassembl e".) 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]

Re: Static typing

Michael Muller wrote:[color=blue]
> In article <3f23ae06$0$210 93$626a54ce@new s.free.fr>, "Bruno Desthuilliers"
> <bdesth.nospam@ removeme.free.f r> wrote:
>[color=green]
>>Michael Muller wrote:
>>Interface documentation may be obtained in others ways (docstring for
>>exemple).[/color]
>
>
> 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)[/color]

It's a management problem, not a programming language issue.
[color=blue]
> - there is no global standard (I might use "name: type info" in my
> docstring, you might use "type name")[/color]

Idem.
[color=blue]
> - 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)[/color]

Idem. If your programmers don't care about keeping doc in sync, you're
in trouble whatever the language.
[color=blue]
> - 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.[/color]

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...
[color=blue]
>[color=green]
>>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...[/color]
>
>
> 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 -[/color]

Right.
[color=blue]
> without it you must do dynamic name
> resolution at runtime.[/color]

Which is a Good Thing IMHO.
[color=blue]
> 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".[/color]

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]

Interface Descriptions - was Re: Static typing

Scott David Daniels wrote:
[color=blue]
> Bruno Desthuilliers wrote:
>[color=green]
>> Michael Muller wrote:
>>[color=darkred]
>>> Is there currently any plan to introduce static typing in any future
>>> version of Python?[/color]
>>
>> Seriously, why would you do that ?[/color]
>
>
> 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][/color]

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)]

Re: Static typing

Tayss wrote:[color=blue]
> 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.[/color]

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.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Michael Muller]

Re: Static typing

In article <3f244eff$0$210 92$626a54ce@new s.free.fr>, "Bruno Desthuilliers"
<bdesth.nospam@ removeme.free.f r> wrote:[color=blue]
> It's a management problem, not a programming language issue.[/color]

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).
[color=blue]
> 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.[/color]

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.

--
Remove the spam and filter components to get my e-mail address.