mix statically typed with dynamically typed

Discussion in 'Python' started by Yingjie Lan, Jan 28, 2010.

  1. Yingjie Lan

    Yingjie Lan Guest

    We all know that Python is dynamically typed, and dynamically typed languages are generally slower than statically typed ones. I wonder if it is possible at all for Python to mix statically-typed-ness with dynamically-typed-ness to boost up its speed a little bit, especially when speed is needed. For example, you define a function like this:

    def speed(float dist, float time):
    return dist/time

    then the compiler would generate code to first check parameter types (or even do some casts if appropriate, say cast an int into float) in the beginning of this function. and the rest of the function would then be compiled with the assumption that 'dist' and 'time' are of the type float.

    Of course, dynamically-typed-ness is still the same as before. Python is well known for providing multiple programming paradigms, I wonder if we could also sneak this in nicely.

    Any thoughts?
    Yingjie Lan, Jan 28, 2010
    #1
    1. Advertising

  2. Am 28.01.10 22:12, schrieb Yingjie Lan:
    > We all know that Python is dynamically typed, and dynamically typed languages are generally slower than statically typed ones. I wonder if it is possible at all for Python to mix statically-typed-ness with dynamically-typed-ness to boost up its speed a little bit, especially when speed is needed. For example, you define a function like this:
    >
    > def speed(float dist, float time):
    > return dist/time
    >
    > then the compiler would generate code to first check parameter types (or even do some casts if appropriate, say cast an int into float) in the beginning of this function. and the rest of the function would then be compiled with the assumption that 'dist' and 'time' are of the type float.
    >
    > Of course, dynamically-typed-ness is still the same as before. Python is well known for providing multiple programming paradigms, I wonder if we could also sneak this in nicely.


    There are various attempts to achieve this.

    The most generic one, which is most promising in the long run is PyPy,
    the implementation of Python in itself, with the added benefit of making
    code-generators that emit e.g. C based on Python-code.

    Then there is Cython, which blends Python with C & integrates very nicely.

    Last but not least, for you actual example, psyco is the easiest thing
    to use, it's a JIT aimed to especially optimize numeric operations as
    the one you present.

    Diez
    Diez B. Roggisch, Jan 28, 2010
    #2
    1. Advertising

  3. * Yingjie Lan:
    [snip]
    >
    > def speed(float dist, float time):
    > return dist/time
    >
    > then the compiler would generate code to first check parameter types
    > (or even do some casts if appropriate, say cast an int into float) in
    > the beginning of this function. and the rest of the function would then
    > be compiled with the assumption that 'dist' and 'time' are of the type
    > float.
    >
    > Of course, dynamically-typed-ness is still the same as before. Python
    > is well known for providing multiple programming paradigms, I wonder if
    > we could also sneak this in nicely.
    >
    > Any thoughts?


    Python already has the /syntax/, e.g.


    >>> def speed( dist: float, time: float ) -> float:

    ... return dist/time
    ...
    >>> print( speed.__annotations__ )

    {'dist': <class 'float'>, 'return': <class 'float'>, 'time': <class 'float'>}
    >>> _



    However, this syntax, while exploitable, is by default nothing but an annotation
    device, like doc strings.

    I'm not sure I like your idea of introducing static typing to increase speed,
    but it could be done without introducing new syntax simply by defining a special
    meaning to such annotation expressions that are 'type' invocations, say, then like

    def speed( dist: type( float ), time: type( float ) ) -> type( float )

    Since there are umpteen projects to increase speed of Python this idea may
    already have been explored...


    Cheers & hth.,

    - Alf (who has some other ideas)
    Alf P. Steinbach, Jan 28, 2010
    #3
  4. * Duncan Booth:
    > "Alf P. Steinbach" <> wrote:
    >
    >> I'm not sure I like your idea of introducing static typing to increase
    >> speed, but it could be done without introducing new syntax simply by
    >> defining a special meaning to such annotation expressions that are
    >> 'type' invocations, say, then like
    >>
    >> def speed( dist: type( float ), time: type( float ) ) -> type(
    >> float )
    >>

    >
    > That would be particularly useless:
    >
    >>>> type(float) is type

    > True
    >
    > So your declaration is identical to:
    >
    > def speed(dist: type, time: type) -> type:


    That's the point.


    > Much better just to stick to something like:
    >
    > def speed( dist: float, time: float ) -> float:
    >
    > where at least you can tell from the annotations what types were actually
    > used.


    No, you do not want to redefine the meaning of existing (actually used) constructs.

    That would be particularly useless, to use your own words. :)


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jan 28, 2010
    #4
  5. Yingjie Lan

    John Nagle Guest

    Yingjie Lan wrote:
    > We all know that Python is dynamically typed, and dynamically typed languages
    > are generally slower than statically typed ones.


    That's mostly a problem with the CPython interpreter, which is a naive
    interpreter. Many dynamically typed languages have implementations which
    optimize out much of the run-time type handling. Shed Skin does this
    for Python. LISP has been doing this better for decades. The JIT
    systems for Javascript also do this.

    Psyco has some explicit typing capability, but it doesn't do much about
    eliminating redundant attribute lookups.

    The two big wins that Python needs for performance are 1) at least
    recognize when a variable can be represented as "long" "double", or
    "char", and 2) recognize when an object or module doesn't need dynamic
    attribute lookup and the attribute slots can be nailed down at compile
    time.

    (Plus, of course, something so that multithreaded programs don't
    suck so bad on multicore CPUs.)

    John Nagle
    John Nagle, Jan 29, 2010
    #5
    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. puzzlecracker
    Replies:
    9
    Views:
    1,577
    puzzlecracker
    Dec 30, 2005
  2. Replies:
    5
    Views:
    617
    Matt Wharton
    Dec 9, 2004
  3. Ville Vainio
    Replies:
    2
    Views:
    353
    Shawn Wheatley
    Jul 16, 2004
  4. puzzlecracker
    Replies:
    4
    Views:
    427
    Luke Meyers
    Dec 25, 2005
  5. Enrique Meza
    Replies:
    0
    Views:
    114
    Enrique Meza
    Jul 24, 2003
Loading...

Share This Page