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

91–100 of 105 posts

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

#91

Post by [deleted] »

bayesian_horse wrote: post #90
londons_explore wrote: post #78

Earlier quoted context omitted.

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

You are wrongly assuming that the core developers are a club that is putting up barriers in order to stay exclusive. Much to the opposite, just like many other big and important open source projects, they are actively trying to recruit, mentor and urge people to come as far "in" as possible. It takes a lot of work and dedication to get acquainted with a code base.

[deleted]

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

#92

Post by marcellus23 »

milliams wrote: post #89
marcellus23 wrote: post #86

Earlier quoted context omitted.

I think you’re thinking of a college frat. Fraternities in this sense are not restricted to men.

I'm not an American and so I have no sense of college frats. I'm thinking of Fraternal Orders which are very explicitly male-only organisations. The word fraternity literally means "brotherhood". The choice of the word "fraternity" by the poster above was deliberate and seems to be being used to imply a more severe exclusion of others.

okay, then you’re thinking of Fraternal Orders, which is also something different. I’m aware of what “fraternity” means etymologically, but I’m sure you’re aware that etymology is separate from meaning.

We don't even have to argue anyway. From a dictionary:

> [treated as singular or plural] a group of people sharing a common profession or interests: e.g. “members of the hunting fraternity”.

Frankly it’s very easy to google.

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

#93

Post by hdjjhhvvhga »

milliams wrote: post #89
marcellus23 wrote: post #86

Earlier quoted context omitted.

I think you’re thinking of a college frat. Fraternities in this sense are not restricted to men.

I'm not an American and so I have no sense of college frats. I'm thinking of Fraternal Orders which are very explicitly male-only organisations. The word fraternity literally means "brotherhood". The choice of the word "fraternity" by the poster above was deliberate and seems to be being used to imply a more severe exclusion of others.

I've understood it the same way. We have fraternities and sororities. A gender-neutral term would be a social club.

However, I've just looked it up in Merriam Webster, and it looks like this term can include female members, too, even thought the word and the related adjective have strong masculine associations. Wikipedia basically says the same, "Although membership in fraternities was and mostly still is limited to men, ever since the development of orders of Catholic sisters and nuns in the Middle Ages and henceforth, this is not always the case. There are mixed male and female orders, as well as wholly female religious orders and societies, some of which are known as sororities in North America."

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

#94

Post by adsharma »

westurner wrote: post #16
rbanffy wrote: post #5

Earlier quoted context omitted.

> I believe it was Dropbox that famously released their own private internal Python build a while back and included some concurrency patches. Google also had their Unladen Swallow version, but it seems they lost interest at some point.

"PEP 3146 -- Merging Unladen Swallow into CPython" > Future Work (2010) https://www.python.org/dev/peps/pep-3146/#future-work Perhaps Google/Grumpy could be updated to compile Python 3.x+ to Go with e.g. the RustPython version of the CPython Python Standard Library modules? "Inside cpyext: Why emulating CPython C API is so Hard" (2018) https://news.ycombinator.com/item?id=18040664 Today, conda-forge compiles CPython…

Grumpy is unmaintained.There is similar work (py2many) that transpiles python3 to 8 different languages.

The approach focuses on functional programming, does away with extensions completely.

For that approach to be successful, a pure python implementation of stdlib in the transpileable subset of python 3 would be super helpful.

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

#95

Post by AlphaSite »

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…

Isn’t this an option change. this Gil still exists in theory iirc.

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

#96

Post by pganssle »

ctoth wrote: post #2

I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine. From Unladen Swallow onward there have been these groups off doing interesting and awesome experiments to try and make Python faster, and they never actually make it into something that Python end-users can use (yes, I know US had shortcomings). This is the work of one…

> I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine.

I think this might be a misunderstanding of the nature of the event that these notes are generated from, unless I'm misunderstanding your objection. The point of this Q&A as I saw it was to explore the feasibility of the idea and fully flesh out the costs and benefits so that we can make informed decisions about how to proceed.

The "random interjections" are notes of caution about what trade-offs need to be made. For example, it is very easy to overlook "dark matter" code because we don't have access to it, but it's almost certainly the majority of Python code out there. It is also not a complete deal-breaker to say that some change could break unknown proprietary extensions — otherwise we'd never be able to change anything; the key is that the changes have to be worth it. A lot of that depends on details — if it's easy to update C extensions for nogil mode (even if they were designed without parallelism in mind), then making breaking changes to remove the GIL might not be so bad. If nogil mode requires that most C extensions totally overhaul their reference counting and C API usage and the changes require restructuring code rather than something that can be done with automated search and replace, that's a much bigger cost and will probably come with a long term fork of the ecosystem (which is a huge pain to deal with) and it might not be worth it.

Avoiding this sort of criticism will not make the underlying problems go away, and I think everyone involved understood that this meeting was intended to bring to light any objections that might guide the work towards ultimate resolution.

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

#97

Post by adgjlsfhk1 »

Siira wrote: post #72
kristofferc wrote: post #32

Earlier quoted context omitted.

Julia is not interpreted.

What’s the difference? Wouldn’t any language with a JIT not be “interpreted”?

Julia isn't a normal jit either. most jits make speculative guesses based on observed patterns and then has to deoptimize occasionally. Julia only compiles based on type information, so in many ways it is closer to running an ahead of time compiler at runtime. because of this, Julia is often called just ahead of time compiled.

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

#98

Post by rbanffy »

Siira wrote: post #72
kristofferc wrote: post #32

Earlier quoted context omitted.

Julia is not interpreted.

What’s the difference? Wouldn’t any language with a JIT not be “interpreted”?

It's not quite interpreted. Python is compiled to bytecode when first loaded (that's what all those .pyc files are) and there is no separate compile step as with Java.

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

#99

Post by yjftsjthsd-h »

moonchrome wrote: post #65
yjftsjthsd-h wrote: post #10

Earlier quoted context omitted.

I mean, PyPy is over a decade old now, and micropython is a mere 7 years old. What's another fork? If anything, I strongly prefer languages that have more than one implementation.

> If anything, I strongly prefer languages that have more than one implementation. What popular languages fall into this category ? I can only think of C/C++ and JavaScript - both seem like terrible examples of languages that took forever to evolve (people still compile down JS to ES5). I'm not sure what the Java story is but I would argue it has been terrible at evolving the language as well. I much prefer languages…

> What popular languages fall into this category ?

Not all, but many. Going down the list of most popular languages from https://www.tiobe.com/tiobe-index/ -

Python - CPython, PyPy, MicroPython

C - numerous (gcc, clang, msvc, tcc, etc.)

Java - https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

C++ - gcc, clang, msvc, etc.

C# - Microsoft's version and mono

Visual Basic - probably only one implementation

JavaScript - https://notes.eatonphil.com/javascript-implementations.html

SQL - assorted dialects, not sure that counts

PHP - probably only one implementation

ASM - assorted dialects, not sure that counts

Classic Visual Basic - probably only one implementation

Go - only one version that matters, AFAIK

MATLAB - probably only one implementation

R - probably only one implementation

Groovy - probably only one implementation

Ruby - https://opensourcelibs.com/lib/ruby-implementations (Why are there so many in Go?)

Swift - probably only one implementation

Fortran - https://fortran-lang.org/compilers/

Perl - probably only one implementation

Delphi/Object Pascal - there are a decent number of Pascals historically, and FPC and Delphi are the big modern options

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

#100

Post by yjftsjthsd-h »

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

Earlier quoted context omitted.

I mean, PyPy is over a decade old now, and micropython is a mere 7 years old. What's another fork? If anything, I strongly prefer languages that have more than one implementation.

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.
Post reply on HN