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

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

261–270 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#261

Post by pansa2 »

wesselbindt wrote: post #254
pansa2 wrote: post #244

Earlier quoted context omitted.

> when you replace the word "aync" with something like "expensive", or "does network calls", it becomes clear that "async/await" makes intrinsic properties about your code explicit rather than implicit. Do you think we should be annotating functions with `expensive` and/or `networking`? And also annotating all of their callers, recursively? And maintaining 4 copies of every higher-order function depending on whether…

So here I think we differ fundamentally in how we like to read code. I much prefer being able to quickly figure out things of interest about a function by glancing at its signature, rather than look at documentation, or worse, having to read the implementation of the function and the functions it calls (and so on, recursively). For example, I much prefer a signature like def f(a: int) -> str: over def f(a): because i…

> Yes, absolutely, and yes, absolutely.

Fair enough, that's a valid philosophy, and one in which `async`/`await` makes perfect sense.

However, it's not Python's philosophy - a language with dynamic types, unchecked exceptions, and racy multithreading. In Python, `async`/`await` seems to be at odds with other language features - it feels like it's more at home in a language like Rust.

Re: Free-threaded CPython is ready to experiment with

#262

Post by gpderetta »

wesselbindt wrote: post #240
throwaway81523 wrote: post #234

Earlier quoted context omitted.

Watch this video and maybe you'll understand ;). Warning, NSFW (lots of swearing), use headphones. https://www.youtube.com/watch?v=bzkRVzciAZg This is also good: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... web search on "colored functions" finds lots of commentary on that article.

I've always found the criticism leveled by the colored functions blog post a bit contrived. Yes, when you replace the words async/await with meaningless concepts I do not care about, it's very annoying to have to arbitrarily mark a function as blue or red. But when you replace the word "aync" with something like "expensive", or "does network calls", it becomes clear that "async/await" makes intrinsic properties about…

Except that at least in python async doesn't mean that. Non async functions can do networking, block, or do expensive operations.

On the other hand async functions can be very cheap.

Again, which useful property does async protect?

Re: Free-threaded CPython is ready to experiment with

#263

Post by pansa2 »

vulnbludog wrote: post #257
pansa2 wrote: post #247

Earlier quoted context omitted.

No-GIL Python is still interpreted - single-threaded performance is slower that standard Python, which is in turn much slower than the languages you mentioned. Maybe if you’ve got an embarrassingly parallel problem, and dozen(s) of cores to spare, you can match the performance of a single-threaded JIT/AOT compiled program.

How do companies like Instagram/OpenAI scale with a majority python codebase? Like I just kick it on HN idk much about computers or coding (think high school CS) why wouldn’t they migrate can someone explain like I’m five

Python may well have been the right choice for companies like that when they were starting out, but now they're much bigger, they would be better off with a different language.

However, they simply have too much code to rewrite it all in another language. Hence the attempts recently to fundamentally change Python itself to make it more suitable for large-scale codebases.

And IMO less suitable for writing small scripts, which is what the majority of Python programmers are actually doing.

Re: Free-threaded CPython is ready to experiment with

#264

Post by wesselbindt »

adament wrote: post #243
wesselbindt wrote: post #240

Earlier quoted context omitted.

I've always found the criticism leveled by the colored functions blog post a bit contrived. Yes, when you replace the words async/await with meaningless concepts I do not care about, it's very annoying to have to arbitrarily mark a function as blue or red. But when you replace the word "aync" with something like "expensive", or "does network calls", it becomes clear that "async/await" makes intrinsic properties about…

But a synchronous function can and many do make network calls or write to files. It is a rather vague signal about the functions behavior as opposed to the lack of the IO monad in Haskell. To me the difficulty is more with writing generic code and maintaining abstraction boundaries. Unless the language provides a way to generalise over asyncness of functions, we need a combinatorial explosion of async variants of gen…

> But a synchronous function can and many do make network calls or write to files

This, for me, is the main drawback of async/await, at least as it is implemented in for example Python. When you call a synchronous function which makes network calls, then it blocks the event loop, which is pretty disastrous, since for the duration of that call you lose all concurrency. And it's a fairly easy footgun to set off.

> It is a rather vague signal about the functions behavior as opposed to the lack of the IO monad in Haskell.

I'm happy you mentioned the IO monad! For me, in the languages people pay me to write in (which sadly does not include Haskell or F#), async/await functions as a poor man's IO monad.

> Again we end up in a place where the most future proof promise to give for an abstraction barrier is to mark everything as async.

Yes, this is one way to write async code. But to me this smells the same as writing every Haskell program as a giant do statement because the internals might want to do I/O at some point. Async/await makes changing side-effect free internals to effectful ones painful, which pushes you in the direction of doing the I/O at the boundaries of your system (where it belongs), rather than all over the place in your call stack. In a ports-adapters architecture, it's perfectly feasible to restrict network I/O to your service layer, and leave your domain entirely synchronous. E.g. sth like

  async def my_service_thing(request, database):
    my_business_object = await database.get(request.widget_id)
    my_business_object.change_state(request.new_widget_color)    # some complicated, entirely synchronous computation
    await database.save(my_business_object)
Async/await pushes you to code in a certain way that I believe makes a codebase more maintainable, in a way similar to the IO monad. And as with the IO monad, you can subvert this push by making everything async (or writing everything in a do statement), but there's better ways of working with them, and judging them based on this subversion is not entirely fair.

> ugly solution: provide 2 versions of each algorithm: an async and a sync

I see your point, and I think it's entirely valid. But having worked in a couple async codebases for a couple of years, the amount of stuff I (or one of my collaborators) have had to duplicate for this reason I think I can count on one hand. It seems that in practice this cost is a fairly low one.

Re: Free-threaded CPython is ready to experiment with

#265

Post by wesselbindt »

pansa2 wrote: post #261
wesselbindt wrote: post #254

Earlier quoted context omitted.

So here I think we differ fundamentally in how we like to read code. I much prefer being able to quickly figure out things of interest about a function by glancing at its signature, rather than look at documentation, or worse, having to read the implementation of the function and the functions it calls (and so on, recursively). For example, I much prefer a signature like def f(a: int) -> str: over def f(a): because i…

> Yes, absolutely, and yes, absolutely. Fair enough, that's a valid philosophy, and one in which `async`/`await` makes perfect sense. However, it's not Python's philosophy - a language with dynamic types, unchecked exceptions, and racy multithreading. In Python, `async`/`await` seems to be at odds with other language features - it feels like it's more at home in a language like Rust.

I completely agree with you. However I've always found the dynamic typing approach to be a bit at odds with

  python3 -c "import this" | head -4 | tail -1
I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. But having worked in large codebases which adopt the same style, and ones that avoid it through static typing and in some cases async/await, the difference in productivity I've noticed in both me and my collaborators is too stark for me to ignore.

I think I should've been more nuanced in my comments praising async/await. I believe that what I say is valid in large IO-bound applications which go beyond basic CRUD operations. In general it depends, of course.

Re: Free-threaded CPython is ready to experiment with

#266

Post by porksoda »

fuzztester wrote: post #221
saagarjha wrote: post #193

Earlier quoted context omitted.

They’re probably downvoting you because you’ve posted like the laziest trope comment there is. lol Python slow everyone is paid to hide the truth amirite

[flagged]

Your comments feel like you want a reddit style battle of wits. You throw words like ignorant around rather freely. I downvote these comments because they lower the tone of the discussion. We're not here to talk about each other or feel smarter than others.. Well I'm not.

Re: Free-threaded CPython is ready to experiment with

#267

Post by setopt »

quotemstr wrote: post #192
sveiss wrote: post #18

Earlier quoted context omitted.

The parser supports the type hint syntax, and the standard library provides various type hint related objects. So you can do things like “from typing import Optional” to bring Optional into scope, and then annotate a function with -> Optional[int] to indicate it returns None or an int. Unlike a system using special comments for type hints, the interpreter will complain if you make a typo in the word Optional or don’t…

> In practice it’s quite usable It would be super helpful if the interpreter had a type-enforcing mode though. All the various external runtime enforcement packages leave something to be desired.

I agree. There are usable third-party runtime type checkers though. I like Beartype, which lets you add a decorator @beartype above any function or method, and it’ll complain at runtime if arguments or return values violate the type hints.

I think runtime type checking is in some ways a better fit for a highly dynamic language like Python than static type checking, although both are useful.

Re: Free-threaded CPython is ready to experiment with

#268

Post by setopt »

zitterbewegung wrote: post #132
nine_k wrote: post #21

Earlier quoted context omitted.

A language server in your IDE kicks in much earlier, and is even more helpful.

I haven't used an IDE that has that but it is still just giving you a hint that there is an error and the interpreter is not throwing an error which was my point.

> I haven't used an IDE that has that

You don’t need an IDE for this, an LSP plugin + Pyright is sufficient to get live type checking. For instance, Emacs (Eglot), Vim (ALE), Sublime (SublimeLSP) all support Pyright with nearly no setup required.

Re: Free-threaded CPython is ready to experiment with

#269

Post by pansa2 »

wesselbindt wrote: post #265
pansa2 wrote: post #261

Earlier quoted context omitted.

> Yes, absolutely, and yes, absolutely. Fair enough, that's a valid philosophy, and one in which `async`/`await` makes perfect sense. However, it's not Python's philosophy - a language with dynamic types, unchecked exceptions, and racy multithreading. In Python, `async`/`await` seems to be at odds with other language features - it feels like it's more at home in a language like Rust.

I completely agree with you. However I've always found the dynamic typing approach to be a bit at odds with python3 -c "import this" | head -4 | tail -1 I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. But having worked in large codebases which adopt the same style, and ones that avoid it through static typing and in some cases async/aw…

> I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like.

Agreed - I only use Python for scripts like this, preferring statically-typed, AOT-compiled languages for larger programs.

That’s why I think Python should have adopted full coroutines - it should play to its strengths and stick to its fast-and-loose style. However, the people who decide how the language evolves are all employees of large companies using it for large codebases - their needs are very different from people who are only using Python for small scripts.

Re: Free-threaded CPython is ready to experiment with

#270

Post by anwlamp »

wokwokwok wrote: post #238
eigenvalue wrote: post #12

Really excited for this. Once some more time goes by and the most important python libraries update to support no GIL, there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects. It's also a good opportunity for new and more actively maintained projects to take market share from older and more established libraries if th…

> there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects This just isn’t true. This does not improve single threaded performance (it’s worse) and concurrent programming is already available. This will make it less annoying to do concurrent processing. It also makes everything slower (arguable where that ends up, curr…

Yes, good summary. My prediction is that free-threading will be the default at some point because one of the corporations that usurped Python-dev wants it.

The rest of us can live with arcane threading bugs and yet another split ecosystem. As I understand it, if a single C-extension opts for the GIL, the GIL will be enabled.

Of course the invitation to experiment is meaningless. CPython is run by corporations, many excellent developers have left and people will not have any influence on the outcome.

Post reply on HN