Yes, using a web UI as a substitute for something like tkinter or one of the other desktop UI frameworks has become a pretty standard practice. It's easier to create a consistent cross-platform UI using the web than most any other mechanism now. -Serdar

I used Microsoft Windows for this demo, no Linux distribution. -Serdar

There's a project called poetry-kernel that may have you covered: github.com/pathbird/poetry-kernel -Serdar

I don't know if he's actually working on the underlying code but he is certainly part of the process that's shepherding "free-threaded Python" (as it's now known) to full release. -Serdar

If you're interested in making DuckDB work with Tableau, there's a whole section in its documentation devoted to it: duckdb.org/docs/guides/data_viewers/tableau -Serdar

Glad it worked! -Serdar

Right now it's the other way around: you'd write your main app in Python, and have the plugins in WebAssembly. Compiling Python to WASM is still a very fraught affair that's nowhere nearly as well-supported as other languages. But that may change in time as WASM itself becomes more robust. -Serdar

git clone github.com/python/cpython.git -Serdar

Thank you

It's part of the standard library, bro. You don't need to pip install anything.

That's a great idea! ast could certainly be the subject of a future video, along with some practical applications for it. -Serdar

My best guess based on experience with FastAPI: the way fast api runs its route handler funcs is if the func is a coroutine (async def) and thus can pause execution during await calls, then it is run on the main thread. If it is a blocking function (def) then it is delegated to the underlying threadpoolexecutor via something like asyncio.to-thread. In my experience, a lot of production code uses just normal functions as opposed to Coroutines for the route handlers due to the relatively recent introduction of async mechanics into the language. If running the no Gil python really has no effect on single threaded code, then at worst this change will have no effect and at best it will give asgi frameworks that work similarly to fastapi a huge speed boost (since those blocking route handler funcs can be executed truly in parallel via the thread pool executor). As far as I know the current best practice is to put non blocking io into async functions and cpu bound tasks into regular functions. Even though Asyncio event loop executes coroutines on the same thread as the event loop, the fact that coroutines are a much lower cost abstraction than threads means that this execution model is faster than using a thread pool. However, the removal of the Gil could change that if the numbers and benchmarks start telling a different story. This may necessitate some internal changes to various asgi frameworks to delegate more coroutines to thread pools as opposed to running them on the main thread. But if your route handler funcs are just regular functions, then out of the box this should yield a major speed increase.

The culprit will be the 3rd party libraries partially unmaintained that most web apps depend on. GIL enabled tons of thread-unsafe code to be written.

thank you for the note!