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

101–105 of 105 posts

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

#101

Post by stjohnswarts »

londons_explore wrote: post #78
milliams wrote: post #77

Earlier quoted context omitted.

> 1 reference to social fraternity membership I'm struggling to find that in the quote. What is the fraternity in question?

"become a core developer" I assume... as if somehow non-core developers are inferior and not-part-of-the-club.

Core developer means that you work on the core, not that you are a person the “python community” can't do without. If one is going to replace the GIL, a very core feature, then it makes sense to make that person a core member of the python squad.

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

#102

Post by stjohnswarts »

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.

They said they would make the non-GIL version opt in (command line flag?) so they wouldn't be breaking the old stuff anyway. It's a solved problem. If anyone moving to a new version of python can't take the time to understand such a small change, then that's on them.

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

#103

Post by boublepop »

nicolaslem wrote: post #53
IshKebab wrote: post #47

Earlier quoted context omitted.

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

And yet the popularity of Python exploded during the 2 to 3 transition. As someone who has migrated a few codebases from 2 to 3, I will gladly do it again to 4 if that brings a GILless Python.

Exactly. The 10% of python programmers who used and loved python 2, keep talking about the community “almost dying” at a time when 90% of it joined with a clear preference for python 3. It’s ridicules.

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

#104

Post by ammar2 »

WesolyKubeczek wrote: post #88
BiteCode_dev wrote: post #74

Earlier quoted context omitted.

Can you give us more details about this ? Do you have a particular story in mind ? It seems a lot of fresh blood is comming to the python project recently, so I'm interested in what you have to say. But why are you using a throwaway account ? And that you that have been answering the other comments with also newly created accounts ?

I can share the sentiment that PSF and the core team has become something like “old boys club”, and no, new core developers didn’t change this ambience you get when you read their forums/mailing lists and twitters (better avoid twitters though). I don’t have anything about a community being an old boys’ club (would be nice to be in one some day, I reckon it’s what older people’s equivalent of a “safe space” is), it’s…

The only reference I can find to "minibosses" is this ancient python-dev thread here (https://mail.python.org/pipermail/python-dev/2001-July/01571...)

> I'd prefer if you didn't feel the need to play miniboss on the Python project

Disclosure: I am a current core dev

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

#105

Post by mvanveen »

yjftsjthsd-h wrote: post #100
mvanveen wrote: post #11

Earlier quoted context omitted.

I do not disagree with you. However, I would speculate part of PSF's hesitancy is likely specifically around the perceived violence that gross' "GIL-less" changes may incur to the runtime semantics' backwards compatibility. PSF in particular has a responsibility here as well I feel in that CPython is arguably the working spec or standard from which these other implementations work and are defined. Do you also strongl…

I can certainly agree that multiple implementations has overhead and creates pain points, but it's not world-ending and it does have advantages.

I think it’s important to ask “what guarantees are in place to keep multiple implementations consistent and what is the fallout if they are not” as a lens to determining the degree to which it is or isn’t “world-ending”

The Python ecosystem once fell apart not too long ago because it was supporting two versions where one moved from “print “ to “print(“ and these were incompatible and broke things such as doc tests.

There’s a reason that ppl strongly started advocating to hard pivot to 3: there was a very real chance that Python 2 could fork the ecosystem.

Incompatible concurrency semantics would be a much worse can of worms.

Post reply on HN