Static typing

Discussion in 'Python' started by Michael Muller, Jul 25, 2003.

  1. 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.
     
    Michael Muller, Jul 25, 2003
    #1
    1. Advertising

  2. 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
     
    Bruno Desthuilliers, Jul 25, 2003
    #2
    1. Advertising

  3. 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
     
    Bruno Desthuilliers, Jul 25, 2003
    #3
  4. Michael Muller

    Aahz Guest

    In article <>,
    Shane Hathaway <> 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 () <*> http://www.pythoncraft.com/

    This is Python. We don't care much about theory, except where it intersects
    with useful practice. --Aahz
     
    Aahz, Jul 25, 2003
    #4
  5. Michael Muller

    Neil Hodgson Guest

    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
     
    Neil Hodgson, Jul 26, 2003
    #5
  6. 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-1.1/node5.html#SECTION00580000000000000000


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

    Shane
     
    Shane Hathaway, Jul 26, 2003
    #6
  7. 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
     
    Scott David Daniels, Jul 26, 2003
    #7
  8. 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
     
    Bruno Desthuilliers, Jul 27, 2003
    #8
  9. Michael Muller

    Tayss Guest

    Bruno Desthuilliers <> wrote in message news:<3f23ae06$0$21093$>...
    > > 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.
     
    Tayss, Jul 27, 2003
    #9
  10. Michael Muller wrote:
    > In article <3f23ae06$0$21093$>, "Bruno Desthuilliers"
    > <> 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
     
    Bruno Desthuilliers, Jul 27, 2003
    #10
  11. Interface Descriptions - was Re: Static typing

    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.
     
    Colin J. Williams, Jul 28, 2003
    #11
  12. 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
     
    Greg Ewing (using news.cis.dfn.de), Jul 29, 2003
    #12
  13. In article <3f244eff$0$21092$>, "Bruno Desthuilliers"
    <> 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.
     
    Michael Muller, Aug 1, 2003
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Digital Puer
    Replies:
    27
    Views:
    5,087
    James Rogers
    Sep 13, 2003
  2. OvErboRed

    Static Typing

    OvErboRed, Jul 26, 2004, in forum: Python
    Replies:
    4
    Views:
    331
    John Roth
    Jul 26, 2004
  3. Optional Static Typing

    , Dec 23, 2004, in forum: Python
    Replies:
    50
    Views:
    1,172
    Jacek Generowicz
    Jan 4, 2005
  4. JimLad
    Replies:
    0
    Views:
    499
    JimLad
    Jan 26, 2010
  5. Charles Oliver Nutter
    Replies:
    4
    Views:
    143
    Rick DeNatale
    Oct 2, 2007
Loading...

Share This Page