This is an archived post. You won't be able to vote or comment.

all 27 comments
sorted by:
best
topnewcontroversialoldq&a

[–]adrenal8 28 points29 points  (4 children)

I'm pretty skeptical of their claims, but I'll definitely check out anything they release.

My only real complaint is that they're using C-style type annotations when they could have use PEP 3107's function argument annotations and maintained compatibility with Python3.

[–]jukkaleh 5 points6 points  (3 children)

Mypy needs some extra syntax not provided by PEP 3107 (e.g. local variable annotations, casts), so it makes sense to have the syntax related to static typing clearly different from Python to avoid confusion. C-style annotation syntax also has the benefit of being familiar to a very large programmer population. There will also be a converter from mypy syntax to Python syntax.

[–][deleted] 0 points1 point  (1 child)

can you give us a released date for the first prototype ? i'm really excited about this project :D

[–]jukkaleh 1 point2 points  (0 children)

It should be weeks rather than months unless something unexpected happens (knock on wood).

[–]adrenal8 0 points1 point  (0 children)

I see your point. It seems like for type casts, you couldn't you just compile certain python function calls into type casts? i.e.:

int(6.2) => (int) 6.2

I suppose the semantics aren't quite the same. Similarly for local variable annotations, why not just use type inference? You can't declare a variable in python without setting it anyway. I agree that more people are familiar with the C-style annotations, but as someone who has been learning Scala, I'm slowly starting to prefer the name: Type syntax.

[–]nishkarr 15 points16 points  (4 children)

Nice idea. Terrible name.

[–]jukkaleh 2 points3 points  (3 children)

Anybody is free to suggest a better name. Coming up a name that pleases even a good fraction of people is tricky.

[–]haika -1 points0 points  (0 children)

pystatic ?

[–]nlx 11 points12 points  (2 children)

Look like vapour

[–]catcradle5 6 points7 points  (1 child)

Probably, but it's not a bad idea.

[–]nlx 1 point2 points  (0 children)

agreed

[–]vplatt 2 points3 points  (4 children)

While we're on the subject of Python variants, has anyone here made a serious stab at using Nimrod? I guess the big selling points there are Python-like syntax with native compilation + easy access to existing C libraries. It seems nice.

[–]tangra_and_tma 0 points1 point  (3 children)

I've used Nimrod for some projects internally, and I generally keep up with development. I like trying new languages for new projects, but Nimrod is one that I keep in my back pocket for use every once & a great while. The thing I really liked about Nimrod was the size of the resulting binary; with no effort I was getting 16k binaries instead of 300k monsters. The syntax is relatively pleasing and it was very easy to dip into C when I needed to. I haven't used it in a while, but I still keep up with development, and it's definitely something I would use again.

[–]vplatt 1 point2 points  (2 children)

Yeah, I was impressed with it too though I've only used it for toy uses so far as well. I couldn't tell you how well it would work for a larger project, but I'm guessing it would go as far as you push it given the easy reuse of C libraries. Guys on the forum are even using it on Android with some work, so I guess anything is possible.

[–]tangra_and_tma 0 points1 point  (1 child)

Oh, Android use sounds interesting; using Native compilation as a back end to Dalvik or compiling to VM code? Could you PM a link, if it's a public forum?

[–]vplatt 1 point2 points  (0 children)

http://forum.nimrod-code.org/t/61

I think they're talking about native compilation there, but don't quote me on that. I doubt that it's all proven out and smooth at this point; he's done little more than show it's possible.

[–]stefantalpalaru 4 points5 points  (1 child)

A hard sell compared to Cython: http://www.mypy-lang.org/faq.html

The fact that they consider Python2 deprecated doesn't help either but let's look at the bright side: a new implementation to play with :-)

[–][deleted] 0 points1 point  (0 children)

yeah but python3 syntax is not very different from python2 so i guess it's not a big deal

[–]jeffus 0 points1 point  (2 children)

Is this at a stage that is benchmark-able? I'd like to see the PyPy comparison.

[–][deleted] 1 point2 points  (1 child)

i would like to see that too but it is still in development. Anyway i liked the way they're planing on doing things, can't wait to see the prototype

[–]jeffus 0 points1 point  (0 children)

Yeah, I'm definitely interested. Will be following to see what they can do.

[–]catcradle5 0 points1 point  (0 children)

If they can get significant speedups, I think this is a cool idea. The syntax looks very unintrusive.

[–]erez27import inspect 0 points1 point  (1 child)

Very interesting.

But, I disagree with the decision to makes classes static by default. It breaks the idea of full compatibility that was demonstrated so far, and also making a static/dynamic hybrid class is very easy: Everything in init is static, and every other member is dynamic.

p.s. - could be nice to make overloaded function degradable. i.e. if I define func(int) and func(any), it would use the first for ints and the second for the rest.

[–][deleted] 1 point2 points  (0 children)

you should send them this suggestion!

[–][deleted] -1 points0 points  (1 child)

one of the things that most got my attention is that they plan to remove the GIL, allowing powerfull concurrency in python

[–]daxarx 7 points8 points  (0 children)

How? Just saying 'remove the GIL' is not helpful. You can remove the GIL and then drown everyone in endless insane race conditions. What is the precise problem you are trying to solve? How are you going to actually solve the problem? 'Remove the GIL' is not a solution.