7 ms·

It would be awesome to combine pypy and mypy. Pypy could probable use static typing to gain some speed.

• thristian 12y ago
  Alex Gaynor, one of the PyPy developers said (on the mailing-list where Guido proposed this): You're right. None of this would provide any value for PyPy. https://mail.python.org/pipermail/python-ideas/2014-August/028623.html https://mail.python.org/pipermail/python-ideas/2014-August/0...
  • Goranek 12y ago
    I certainly didn't expect this, but he is right.
  • andreasvc 12y ago
    Why is that?
    • untothebreach 12y ago
      Because in a dynamically typed language like Python, it is perfectly feasible that the type declared in the code, and type-checked before the program runs, is different when the piece of code actually _runs_. Pypy uses runtime types to make decisions about optimizations, and since those may be different than the types declared at compile time, it will always have to inspect the runtime type anyway.
      • andreasvc 12y ago
        Then the type annotation is wrong, and it shouldn't be there. Type annotations only make sense if you know exactly what the types may be at runtime. I still don't see why correct annotations couldn't help PyPy.
        • untothebreach 12y ago
          Type-checking _via_ those annotations, are, like Guido said, basically a souped-up linter. With a dynamic language like Python, there is _never_ a guarantee that the types that type-checked during compilation are the types that will be observed during runtime. Type-checking Python code via function annotations is nothing like type checking a Haskell program, where you can be reasonably certain that a program that type-checks will run correctly. Even if you write a program that you can provably show will never have any runtime types that differ from compile time types, Pypy can't assume that will be the case with every program that it tries to run. I don't have any specific knowledge of the optimizations that Pypy runs, but if one of the core contributors of Pypy says it can't be done, I'm inclined to believe him.
          • andreasvc 12y ago
            It is trivial to write a function that always returns a specific type, e.g., def f(): return 1 Therefore your claim that there is "_never_ a guarantee" is simply false. I was asking: what if you DO want PyPy to assume that your types are correct, why couldn't that help?
            • bjt 12y ago
              In Python you have no guarantee that that function hasn't been monkeypatched over and replaced by some other library you imported.
              • andreasvc 12y ago
                From what I read those things are problematic for PyPy anyway, causing it to fallback to an unoptimized interpreter. Also, the type annotations could be interpreted as a promise that what is being annotated will not be monkeypatched at runtime. What is a type annotation, if not a promise that something is not as dynamic as it could otherwise be?
            • untothebreach 12y ago
              Monkeypatching means that `def f(): return 1` could be turned into `def f(): return "i am now a string!"` at runtime, so I stand by my original statement. EDIT: Here is a trivial example of a program that type checks at compile time but doesn't present the same types at runtime. Obviously you would never do this in production code, but the same effect could be accomplished simply by doing an `import somemodule`. http://codepad.org/OarBYXfZ http://codepad.org/OarBYXfZ
  • deleted 12y ago
    [deleted]