3 ms·

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 simp

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
- andreasvc 12y ago
  Your replacing what 'f' is bound to; this would include replacing any type annotations, and triggering any system that relies on type annotations to drop/reset its optimizations for 'f'. You're not actually rewriting the original function to return something different; this would probably also be possible, but would be considered as even more of a dirty trick. It is unfortunate that such dynamicity is the default in Python, when in reality it is rarely needed. So it would be advantageous to be able to tell the optimization system: this function is not going to change dynamically (on an opt-in basis).
DasIch 12y ago
You could replace the code object at runtime changing what the function does and what the type of the returned object is.

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

andreasvc 12y ago
Your replacing what 'f' is bound to; this would include replacing any type annotations, and triggering any system that relies on type annotations to drop/reset its optimizations for 'f'. You're not actually rewriting the original function to return something different; this would probably also be possible, but would be considered as even more of a dirty trick. It is unfortunate that such dynamicity is the default in Python, when in reality it is rarely needed. So it would be advantageous to be able to tell the optimization system: this function is not going to change dynamically (on an opt-in basis).

DasIch 12y ago

You could replace the code object at runtime changing what the function does and what the type of the returned object is.