5 ms·

The latest version does allow you to decorate variables with types... Not sure its doing anything with them yet.

Animats 10y ago
It's not. See [1]. The retrofitting of type declarations to Python is taking a very strange path. (Evil interpretation: this is an effort by Python's little tin god to sabotage PyPy. Type information is a huge win for a compiler; it can now generate hard code for a specific type. It doesn't help CPython much, since inside CPython everything is a CObject. With type information, one could write things like NumPy, with its arrays of uniform type and functions which operate on them, in Python. The PyPy compiler could then generate efficient code for them. This would make PyPy the primary Python compiler. But if type annotation isn't enforced in CPython, code won't port reliably to a compiler which enforces it.) [1] https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/
- weberc2 10y ago
  How is this "sabotaging" PyPy? Also, even with type declarations, I'm not sure you could get Numpy-esque performance, given that Numpy doesn't have to dereference every element in the array.
  - Animats 10y ago
    If the compiler knows a Python array is uniformly of type float, it can, and should, use a dense array of floats to represent it.
    - weberc2 10y ago
      Is this safe in all cases? What about complex types? Specifically if you assign a variable to an element in the array, and then replace the element in the array? You'd have to take care not to update the value of the variable.
      - Animats 10y ago
        Assigning a variable to a destination declared to be an incompatible type should produce an error at compile time if possible, and at at run time otherwise. That's what type declarations are all about.
        weberc2 10y ago
        I think you misunderstand. Here's an example: ``` foos = [Foo(a=0), Foo(a=1)] f0 = foos[0] foos[0] = Foo(a=2) print(f0.a) # 0 print(foos[0].a) # 2 ``` `foos` is a list of type `Foo`, but it still can't be safely made into a dense list (at least not naively).
        sanxiyn 10y ago
        You are right. Array elements need to have value semantics to do complete unboxing. But for NumPy-like use cases, they do. It should be noted that PyPy already does unboxing Animats suggested, without any type annotation. At least for 4 years. It is not theoretical. https://morepypy.blogspot.com/2011/10/more-compact-lists-with-list-strategies.html https://morepypy.blogspot.com/2011/10/more-compact-lists-wit...
      - sevensor 10y ago
        Python's arrays are already typed, and have been for long years. Python's lists may hold arbitrary objects and would be much harder to reason about in this context.

It's not. See [1]. The retrofitting of type declarations to Python is taking a very strange path. (Evil interpretation: this is an effort by Python's little tin god to sabotage PyPy. Type information is a huge win for a compiler; it can now generate hard code for a specific type. It doesn't help CPython much, since inside CPython everything is a CObject. With type information, one could write things like NumPy, with its arrays of uniform type and functions which operate on them, in Python. The PyPy compiler could then generate efficient code for them. This would make PyPy the primary Python compiler. But if type annotation isn't enforced in CPython, code won't port reliably to a compiler which enforces it.) [1] https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/

weberc2 10y ago
How is this "sabotaging" PyPy? Also, even with type declarations, I'm not sure you could get Numpy-esque performance, given that Numpy doesn't have to dereference every element in the array.
- Animats 10y ago
  If the compiler knows a Python array is uniformly of type float, it can, and should, use a dense array of floats to represent it.
  - weberc2 10y ago
    Is this safe in all cases? What about complex types? Specifically if you assign a variable to an element in the array, and then replace the element in the array? You'd have to take care not to update the value of the variable.
    - Animats 10y ago
      Assigning a variable to a destination declared to be an incompatible type should produce an error at compile time if possible, and at at run time otherwise. That's what type declarations are all about.
      - weberc2 10y ago
        I think you misunderstand. Here's an example: ``` foos = [Foo(a=0), Foo(a=1)] f0 = foos[0] foos[0] = Foo(a=2) print(f0.a) # 0 print(foos[0].a) # 2 ``` `foos` is a list of type `Foo`, but it still can't be safely made into a dense list (at least not naively).
        sanxiyn 10y ago
        You are right. Array elements need to have value semantics to do complete unboxing. But for NumPy-like use cases, they do. It should be noted that PyPy already does unboxing Animats suggested, without any type annotation. At least for 4 years. It is not theoretical. https://morepypy.blogspot.com/2011/10/more-compact-lists-with-list-strategies.html https://morepypy.blogspot.com/2011/10/more-compact-lists-wit...
    - sevensor 10y ago
      Python's arrays are already typed, and have been for long years. Python's lists may hold arbitrary objects and would be much harder to reason about in this context.