Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mypy - An experimental Python variant with dynamic and static typing

mypy-lang.org

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Mypy - An experimental Python variant with dynamic and static typing

#21

Post by winter_blue »

andrewcooke wrote: post #6

why doesn't this use the python standard for adding type information? it should be: def foo(n: int): not def foo(int n): then it would be valid python 3 code (and would also work with pytyp (disclaimer: mine)). http://docs.python.org/py3k/reference/compound_stmts.html#fu... http://www.python.org/dev/peps/pep-3107/ http://www.acooke.org/pytyp/

Thanks for mentioning pytyp!

I have been using this recipe: http://code.activestate.com/recipes/572161/ to add type checking to Python for a while now, so it's nice to see a more mature and developed library that does the same (and more.)

In your code examples I didn't see any decorators around the functions that were being typechecked, so how do you then enforce the type checking?

In addition, is pytyp as fully-featured as the recipe above? (The recipe is short but well-written.) The comments at the beginning of the recipe shows a bunch of examples that demonstrate all that it can do.

Re: Mypy - An experimental Python variant with dynamic and static typing

#22

Post by andrewcooke »

winter_blue wrote: post #21
andrewcooke wrote: post #6

why doesn't this use the python standard for adding type information? it should be: def foo(n: int): not def foo(int n): then it would be valid python 3 code (and would also work with pytyp (disclaimer: mine)). http://docs.python.org/py3k/reference/compound_stmts.html#fu... http://www.python.org/dev/peps/pep-3107/ http://www.acooke.org/pytyp/

Thanks for mentioning pytyp! I have been using this recipe: http://code.activestate.com/recipes/572161/ to add type checking to Python for a while now, so it's nice to see a more mature and developed library that does the same (and more.) In your code examples I didn't see any decorators around the functions that were being typechecked, so how do you then enforce the type checking? In addition, is pytyp as fully-feat…

huh. i will fix that, thanks. there should be a @checked annotation on the function that is checked in the example there.

pyptyp is pretty comprehensive. for example, Rec(a=Seq(Opt(int)),b=Alt(float,str)) is the type for something like a dict where a is a list that contains ints or None and b is either a float or a string.

BUT it's pure python so it's not at all fast. i wouldn't use type checking throughout a codebase - only for debugging, or tests.

it's perhaps more useful as a start for building other things. for example, it includes mapping from JSON to python objects - it can use type annotations to guide the construction of python objects from JSON lists and maps. but on the other hand the internals are quite complex (i have been working with it recently, after not using it for a year or so, and it's taken some effort to understand everything).

Re: Mypy - An experimental Python variant with dynamic and static typing

#23

Post by ippisl »

bugsbunnyak wrote: post #2

From the FAQ: The initial compiler will compile into C or use LLVM for the back end This is .. a rather fundamental point. More critically, there is no link that I could see to any code. It is an interesting idea, but it seems a little too under-cooked to merit much discussion right now. However, one way that this could get really good traction is if it were to support Cython code (which doesn't seem to be the case,…

From their homepage:

Access to Python libs

Mypy will support accessing Python modules from mypy programs, running in the stock CPython virtual machine for the best compatibility. You can also access your existing Python code.

Re: Mypy - An experimental Python variant with dynamic and static typing

#24

Post by jules »

andreasvc wrote: post #17
JulianWasTaken wrote: post #11

Earlier quoted context omitted.

This is not true. There have been plenty of successful attempts to remove the GIL, including from CPython. It's not impossibly hard to do so by a long shot. The GIL is an optimization though, and so the performance hit from removing it on single threaded code is prohibitive. You can watch any of David Beazley's talks on the GIL for more info.

Prohibitive is too strong I think. The patch to 1.4 discussed in a blog post by Beazley came with a 2x slow down, but that was an initial patch without much work on optimization. Besides that, I think 2x slowdown isn't that bad considering the language is not used for its raw efficiency anyway.

Well, the only reason to remove it is to run multiple Python threads in parallel for efficiency...so efficiency is definitely the top concern here.

Re: Mypy - An experimental Python variant with dynamic and static typing

#25

Post by reinhardt »

andrewcooke wrote: post #22
winter_blue wrote: post #21

Earlier quoted context omitted.

Thanks for mentioning pytyp! I have been using this recipe: http://code.activestate.com/recipes/572161/ to add type checking to Python for a while now, so it's nice to see a more mature and developed library that does the same (and more.) In your code examples I didn't see any decorators around the functions that were being typechecked, so how do you then enforce the type checking? In addition, is pytyp as fully-feat…

huh. i will fix that, thanks. there should be a @checked annotation on the function that is checked in the example there. pyptyp is pretty comprehensive. for example, Rec(a=Seq(Opt(int)),b=Alt(float,str)) is the type for something like a dict where a is a list that contains ints or None and b is either a float or a string. BUT it's pure python so it's not at all fast. i wouldn't use type checking throughout a codebas…

Another similar project: https://github.com/podio/valideer. The (rough) equivalent schema for the example above can be expressed as {"a": ["?integer"], "b": AnyOf("number", "string")}.

Re: Mypy - An experimental Python variant with dynamic and static typing

#26

Post by bugsbunnyak »

ippisl wrote: post #23
bugsbunnyak wrote: post #2

From the FAQ: The initial compiler will compile into C or use LLVM for the back end This is .. a rather fundamental point. More critically, there is no link that I could see to any code. It is an interesting idea, but it seems a little too under-cooked to merit much discussion right now. However, one way that this could get really good traction is if it were to support Cython code (which doesn't seem to be the case,…

From their homepage: Access to Python libs Mypy will support accessing Python modules from mypy programs, running in the stock CPython virtual machine for the best compatibility. You can also access your existing Python code.

Cython, not CPython. I took it as a given that it will run "pure" CPython-compatible code. I meant that the ability to JIT down Cython code (without the C translation step) would be a strong hook to get some people interested. There have been steps toward this in PyPy, and I expect it will happen in Numba sooner or later.

This would actually be even more compelling that I initially thought, since you pointed out that mypy run in stock CPython (I overlooked that and assumed it would have separate interpreter). All hypothetical, of course -- where's the github link?

Re: Mypy - An experimental Python variant with dynamic and static typing

#28

Post by iandanforth »

danbmil99 wrote: post #7

Boo, Shed-skin

For people who don't know what you're talking about:

Boo - http://boo.codehaus.org/

Shed-skin - http://code.google.com/p/shedskin/

Both are projects that take a crack at adding or creating a static type system in concert with Python like syntax. The above take very different approaches.

Re: Mypy - An experimental Python variant with dynamic and static typing

#29

Post by jhrobert »

What about "hints"?

  def foo( often int n ):
This one would generate both the dynamic & the static versions.

Once all call sites stop using the dynamic version, one can move on to strict typing (and remove the "often" qualifier), if such is the goal.

Think of it like the old "register" hint in C code (now obsolete).

Re: Mypy - An experimental Python variant with dynamic and static typing

#30

Post by andreasvc »

jules wrote: post #24
andreasvc wrote: post #17

Earlier quoted context omitted.

Prohibitive is too strong I think. The patch to 1.4 discussed in a blog post by Beazley came with a 2x slow down, but that was an initial patch without much work on optimization. Besides that, I think 2x slowdown isn't that bad considering the language is not used for its raw efficiency anyway.

Well, the only reason to remove it is to run multiple Python threads in parallel for efficiency...so efficiency is definitely the top concern here.

No the reason to remove it is to get parallelism from threads. Once you have parallelism, you can overcome a 2x slow down for a single thread by using more cores.
Post reply on HN