Adding static typing to Python

[gbreed at cix.compulink.co.uk]

Justin Sheehy wrote:

> Those terms are used fairly often in programming language
> discussions.  Many languages use the static/dynamic distinction to
> describe their own typing system.

Thanks for the examples.  Yes, static/dynamic typing does seem to exist in 
the real world :-)

> > The only definition I have to hand contradicts it:
> > <http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=strong+typing>
> 
> So, if we're just going to pick definitions off the web, here's one
> that appeared rather quickly on google:

Hang on, I wasn't "picking definitions off the web".  That's the only 
technical dictionary I had to hand.  I wouldn't expect anybody casually 
mentioning "strong typing" to have a better one.  I happened to find 
another in preparing this message

<http://www.harcourt.com/dictionary/def/9/9/2/7/9927800.html>

that equates strong with static typing.  It looks like "strong typing" 
doesn't have a universally agreed definition, so I suppose the best thing 
is to avoid the term.

Out of general interest, does anybody know of a dictionary I *can* rely on 
for these kind of definitions?

> A common interpretation/explanation of this is that dynamic typing
> assigns types to values, while static typing assigns types to
> variables.  This is in line with my statement about Python's strong
> yet dynamic typing.

That makes sense as regards static/dynamic, thanks.  So the argument for 
adding optional static typing is for names to have types associated with 
them, which is consistent with types being declared for function 
arguments.

If the type was declared only for the initial assignment, for example

def cons(element, stuff: tuple):
  stuff = list(stuff)
  stuff.append(element)
  return tuple(stuff)

would that still be static typing?

> > Taking "static typing" literally would probably mean that an object 
> > couldn't change it's type after creation.  That's almost always the 
> > case in Python.  If you mean identifiers have to stay bound to the 
> > same type, it'd mean
> >
> > x = 1
> > x *= 5L
> >
> > would be illegal, because x begins as an integer and then becomes a 
> > long.  
> 
> This shows that you don't yet understand Python's assignment rules.

How does it show this??????  How ever badly I understand the terminology, 
I thought I had a good knowledge of Pythonic assignment.  Certainly 
nothing in the explanation below is new to me.

> In the above, no object is changing type.  The following is what 
> happens:
> 
>  - An object of type integer is created.
>  - The name "x" is bound to that object.
>  - An object of type long is created.
>  - The name "x" is bound to that object.
> 
> The binding of names to objects is completely independent from the
> values of the objects.  Objects have types in dynamically-typed
> languages, but names may not.

Yes, and the example was of an identifier being bound to a different type. 
 I never said any objects were changing type.  Here's an example of that:

Python 2.2 (#1, Dec 31 2001, 15:21:18)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Test1(object): pass
...
>>> class Test2(object): pass
...
>>> test = Test1()
>>> test.a=1
>>> type(test)
<class '__main__.Test1'>
>>> test.__class__ = Test2
>>> type(test)
<class '__main__.Test2'>
>>> test.a
1


                 Graham

     (http://www.microtonal.co.uk/)