By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,077 Members | 1,175 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,077 IT Pros & Developers. It's quick & easy.

Static typing

P: n/a
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.

Jul 18 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Michael Muller wrote:
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

Jul 18 '05 #2

P: n/a
Michael Muller wrote:
Is there currently any plan to introduce static typing in any future
version of Python?


Seriously, why would you do that ?

Bruno

Jul 18 '05 #3

P: n/a
Bruno Desthuilliers wrote:
Michael Muller wrote:
Is there currently any plan to introduce static typing in any future
version of Python?

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
Sc***********@Acm.Org

Jul 18 '05 #4

P: n/a
In article <ma**********************************@python.org >,
Shane Hathaway <sh***@zope.com> wrote:

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

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

P: n/a
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-...00000000000000
00

Neil
Jul 18 '05 #6

P: n/a
On 07/25/2003 07:36 PM, Neil Hodgson wrote:
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-...00000000000000


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

Shane
Jul 18 '05 #7

P: n/a
Michael Muller wrote:
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

Jul 18 '05 #8

P: n/a
Bruno Desthuilliers <bd***********@removeme.free.fr> wrote in message news:<3f***********************@news.free.fr>...
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).


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.
Jul 18 '05 #9

P: n/a
Michael Muller wrote:
In article <3f***********************@news.free.fr>, "Bruno Desthuilliers"
<bd***********@removeme.free.fr> wrote:
Michael Muller wrote:
Interface documentation may be obtained in others ways (docstring for
exemple).

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...
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...

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

Jul 18 '05 #10

P: n/a
Scott David Daniels wrote:
Bruno Desthuilliers wrote:
Michael Muller wrote:
Is there currently any plan to introduce static typing in any future
version of Python?


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.

Jul 18 '05 #11

P: n/a
Tayss wrote:
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.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Jul 18 '05 #12

P: n/a
In article <3f***********************@news.free.fr>, "Bruno Desthuilliers"
<bd***********@removeme.free.fr> wrote:
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.

--
Remove the spam and filter components to get my e-mail address.
Jul 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.