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

Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

lukasz.langa.pl

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#41

Post by josefx »

didip wrote: post #22

I think Python core developers should not worry about closed-source enterprise Python code. If users are gaining performance, they will bend over backward porting their code to this new version. At minimum, I predict, all FAANGMULA would jumped in the bandwagon and create a pretty big ripple effect.

I am surprised that closed source is suddenly an issue when it comes to the GIL, but half the world breaking on the python 3 transition was not only intended but actively pushed by various members of the community. Since Linux managed to get rid of the BLK then python should be able to get rid of the GIL.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#42

Post by bionhoward »

jancsika wrote: post #26

Suppose a Python module written in C registers a method that ends up making a call to C functions larry(), moe(), and then curly() to mutate a global variable "global_mutable_temp" before finally returning a value generated from global_mutable_temp. 1. Supposing this method doesn't currently crash under GIL python, would it be true that this method will also run without crashing on the non-GIL python interpreter? 2.…

No, yes, and that code should be rewritten, GIL or not

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#43

Post by kombine »

I think switching the version to 4 is the most viable path. Make the last GILed python 3 an LTS release that interested parties can hold on to, eg. Ubuntu can keep python 3 as a default for a long time. One can always use conda to run multiple versions simultaneously.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#44

Post by drothlis »

rectang wrote: post #20
vlovich123 wrote: post #14

Earlier quoted context omitted.

Is there some particular reason to believe the Python team is even able to get good insight into regressions in the long tail of python packages? Also it's important to remember that a lot of of material contributions to the community (either to the foundation, via jobs, or even open-sourcing part of their internal stack) might be coming from closed source in some way. It's not wise to ignore that & I think the core…

Concurrency is impossible to prove sound without language-level guarantees. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-... I'm astounded that a change which will release untold heisenbugs into the wild is being considered. It changes my view of Python. In terms of inducing subtle, silent breakage in existing code, it reminds me of this horrifying change from PHP 8: https://www.php.net/manual/en/migra…

> The GIL will still be optionally available as an interpreter startup-time option

Sounds like they’re going to make it opt-in (or opt-outable) if they do merge it.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#46

Post by caffzz »

frazbin wrote: post #25

I think there's a pretty good chance this stuff gets incorporated: "On a personal level, we are impressed by Sam’s work so far and invited him to join the CPython project. I’m happy to report he is interested, and to help him ramp up to become a core developer, I will be mentoring him. Guido and Neil Schemenauer will help me review code for the interpreter bits I’m unfamiliar with."

Embrace, extend, extinguish. Sam will be in for a rude awakening with these people.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#47

Post by IshKebab »

kombine wrote: post #43

I think switching the version to 4 is the most viable path. Make the last GILed python 3 an LTS release that interested parties can hold on to, eg. Ubuntu can keep python 3 as a default for a long time. One can always use conda to run multiple versions simultaneously.

You mean Python 4? That would be absolutely insane. Have you already forgotten the 2/3 transition? They aren't making that mistake again.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#48

Post by berkut »

IshKebab wrote: post #47
kombine wrote: post #43

I think switching the version to 4 is the most viable path. Make the last GILed python 3 an LTS release that interested parties can hold on to, eg. Ubuntu can keep python 3 as a default for a long time. One can always use conda to run multiple versions simultaneously.

You mean Python 4? That would be absolutely insane. Have you already forgotten the 2/3 transition? They aren't making that mistake again.

Maybe not, but as someone in the VFX/CG industry where Python 3 is only just being moved to this year (still on 2.7 mostly) because we didn't really need unicode, getting rid of the GIL in 3.0 would have very likely made us jump to Python 3 almost instantly years ago.

Different people want different things I guess...

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#49

Post by jas0so »

IshKebab wrote: post #47
kombine wrote: post #43

I think switching the version to 4 is the most viable path. Make the last GILed python 3 an LTS release that interested parties can hold on to, eg. Ubuntu can keep python 3 as a default for a long time. One can always use conda to run multiple versions simultaneously.

You mean Python 4? That would be absolutely insane. Have you already forgotten the 2/3 transition? They aren't making that mistake again.

Just because the version increments doesnt mean it'll be as painful a transition.

Re: Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

#50

Post by antman »

TLDR of my understanding:

What python commitee considered as infeasible was almost done by a lone hero. Since the previous decision to change the format of the print function (that no one asked for) broke everybody's code for no reason and took ten years to be adopted, they will not push (for the one change everyone wants) for the foreseable future. Although it does not seem to be that impossible after all.

I am glad they will invite Sam, the lone gero we needed and hope he will be given some ownership of the task and not get him swamped with commiteeisms through a embrace, not extend and extinguish. He is on a success path, the commitee is in no path at all.

Just put a timeline and call it a fail if don't succeed and quit avoiding it through "discussions". We got it, it's not planned for the X.XX+1 version, each version.

Post reply on HN