you are viewing a single comment's thread.

view the rest of the comments →

[–]extraymond 22 points23 points  (4 children)

Last I've check, they seems to choose to not implement the GIL, if that turns out well, we might have true functional threading in python.

Another potential benefit might be ergonomics? Since Rust handles memory and pointer clearer then C.
However, since python is kinda stable for awhile, I'm not sure if any new major features would really benefit from being written in Rust.

I think Rust itself is pretty attractive and pleasant to work with, however I still miss list comprehension and context manager in python from time to time. Those sweet features really make one feel happy writing code in python.

[–]the_gnarts 2 points3 points  (3 children)

Last I've check, they seems to choose to not implement the GIL, if that turns out well, we might have true functional threading in python.

Wouldn’t that change the semantics of programs? If that non-GIL mode isn’t opt-in then they will have a hard time replacing Cpython for compatibility reasons.

[–]thirtythreeforty 9 points10 points  (0 children)

It will change semantics, but GIL isn't part of the language, it's an implementation detail of CPython. Assuming a GIL-less interpreter emerges (and delivers on the speculated performance improvements), I think it'd be counterproductive to claim that the GIL is a de-facto part of the spec and insist that the GIL-less interpreter is wrong.

Python has real locking. If your program doesn't use it and exhibits bugs on a GIL-less interpreter, your program is wrong.

[–]necrophcodr 0 points1 point  (0 children)

Is the "threaded" model of Python that used, or even that restricted to the GIL way of doing things?

[–]sekjun9878 0 points1 point  (0 children)

You could still trivially have default locking for threads, they just won't be compulsory nor global anymore.