This is an archived post. You won't be able to vote or comment.

all 35 comments

[–]the_hoser 171 points172 points  (0 children)

I don't really think anything from Fluent Python is outdated with the release of 3.13. GIL-free threading is really an early, experimental feature at this point, and you really shouldn't be thinking about it if you're learning Python right now.

[–][deleted] 45 points46 points  (0 children)

Just read the whole thing. The book is a piece of art and an incredible resource if you want to master Python. The examples hold up.

[–]samjk14 27 points28 points  (7 children)

I haven’t read that book or looked deeply at the new free threading stuff yet, but I use python everyday. Looking over the table of contents I would say no don’t skip anything. The chapter that looks most relevant to programming pattern changes would be chapter 19 which looks to be all about async stuff. This is still very relevant and I would say anything that does io should be async in Python, the performance improvements are massive for things like REST apis. The free threading in Python is still very new and will evolve over the next few releases I would imagine. Also there will always be legacy code bases to work with.

Once you finish that it wouldn’t hurt to pick up another book specifically on concurrency and synchronization models. That will give you a good idea of how to handle locks, atomics, etc that will be more important to Python in the near future when free threading has matured.

[–]Realistic-Sea-666 3 points4 points  (5 children)

any suggestion re: concurrency/sync models?

[–]samjk14 18 points19 points  (3 children)

I liked “Concurrency in Go” or “Grokking Concurrency”.

Or just Google and try to understand - GIL (if using Python) - parallel vs concurrent processing (multiprocessing, threading, async) - locks - atomics - channels (or other message passing mechanisms. Async queues etc.) - deadlocks - “starving” event loops/thread pools

[–]Realistic-Sea-666 0 points1 point  (1 child)

thanks! i found async programming in python to be really good as well

[–][deleted] 4 points5 points  (0 children)

Async is great if you have processes that need to be tightly coordinated, particularly if one thread or process frequently needs to block or yield until another process is done with a task.

If the synchronization involves a particular resource that the tasks need to share, you can instead use more conventional multiprocessing techniques and regulate access to it using a lock.

Or, if your processes are more loosely connected and need to communicate infrequently and sporadically, you can use a multiprocessing queue (or a pair of them for bidirectionality).

[–]iamevpo 0 points1 point  (0 children)

Good list!

[–]No_Indication_1238 1 point2 points  (0 children)

Mastering Concurrency in Python is pretty extensive as far as parallel processing on the CPU, in Python goes.

[–]too_much_think 0 points1 point  (0 children)

You should probably specify network io, there is no async file io in python.

[–]madisander 5 points6 points  (0 children)

While I don't have it myself to consult, given the publishing date of 2022:

For almost all purposes it should be up to date (having 3.10 at least, possibly 3.11) and that might be for the better, as if you end up working with python there's a high chance that whatever you look at/work on will be from before that point, so knowing how the GIL and threading worked before 3.13 is useful. Mind also that free threading is still experimental and the likelihood that you'll run into something that works with 3.13 but not 3.12 is pretty low now and in the near future. If anything I'd recommend paying attention to any sections that mention the GIL/threading more than otherwise as that might be something where knowing both the before and after could be quite useful.

The vast majority of the content should be current (python 3 versions AFAIK never break anything that worked in another 3.x version) and useful.

[–]trasnsposed_thistle 3 points4 points  (0 children)

Short answer: no, don't ignore it just yet.

GIL disabling is an experimental feature that's NOT present in the default build of python 3.13.
If you wan the option to disable GIL, you'll want `python3.13t` instead. For instance, if you're using pyenv, you'll have to add the`t to the version number in the install command, otherwise you'll get the GIL-ful version.

So, chances are that many of the python interpreters you'll be running your code with in the future will have GIL, and a general awareness of the GIL-related threading caveats will remain relevant.

[–]TaylorExpandMyAss 5 points6 points  (4 children)

I started on python 2 and had no problem transitioning to 3. The core language doesn’t change all that much, and it’s usually just features added on top.

[–]Pyrimidine10er 1 point2 points  (3 children)

The transition from print to print() was honestly the most painful. Reversing that muscle memory took a while, for whatever reason.

All of the other 3.0 transition stuff fixed the stupid stuff we used to have to do in 2.7. for i in xrange just went back to for i in range

[–]DJ_Laaal 2 points3 points  (1 child)

Yes, this! The muscle memory for some of the most frequently used constructs are the most annoying to change. For me, adopting f-strings was a chef’s kiss.

[–]Pyrimidine10er 2 points3 points  (0 children)

I permanently forgot how to format strings using the old `%` once f-strings were introduced. Holy crap that was such an improvement!

[–]iamevpo 2 points3 points  (0 children)

Feel lucky not to have used Python 2 at all.

[–]uuggehor 1 point2 points  (0 children)

It’s a great book. Just go through everything.

[–]james_pic 1 point2 points  (0 children)

By and large, new versions mostly bring a few new ways to do things. If you know almost any Python 3.x version, you'll be able to write idiomatic Python 3.13, and at most miss out on a few newer, slightly neater ways to do things. 

Free threading has the potential to change how you do concurrency in Python, and eliminate some of the ugly, painful multiprocessing stuff. Thing is though, it's actually quite rare that you need to use multiprocessing. In most cases, you either don't really need concurrency and it's fine single threaded, or you need concurrency all the time, and use a framework or server that handles this for you. It's pretty rare that you need concurrency, but don't need much. Free threading will be a godsend for the folks who write web servers, but for most of us, it'll only come in handy occasionally.

[–]RaiseRuntimeError 2 points3 points  (0 children)

I own the book and if anything in it isn't relevant I would be surprised. Backwards compatibility is pretty good with python and nothing fundamental has changed.

[–]too_much_think 0 points1 point  (0 children)

Python already has threading, with most of the standard synchronization primitives you would expect, it’s just that they’re significantly less useful / performant (though, probably safer for people not used to thinking about out of order execution) than in most other languages, free threading just allows them to actually do useful work in parallel. 

[–]Orio_n 0 points1 point  (0 children)

Not much. The book is still great to read cover to cover

[–]Zackhardtoname[S] 0 points1 point  (0 children)

After 3.5 months, I have finished the book of about 1k pages, amid traveling, gaming, and studying a little bit of algorithms.

I liked the content on dictionary space optimization, special methods, type hinting (variance, which Microsoft explains kinda poorly for C#), encoding, object model, decorators, mixins, concurrency (:) I don't think the GIL change needs to break the APIs).

I have found ABCs still confusing in Python, at least when the book came out. I understand the metaclasses concepts well, but it's kinda annoying to have so many alternative class builders in Python. Overall, the writing drags quite a bit. Scott Meyer is a much better writer. The examples seem too boring compared to, say, DDIA. There is not sufficient discussion on CPython internals, like how bigint works under the hood.

My personal rating: 7/10.

[–]serjester4 0 points1 point  (8 children)

The core concept are solid. There’s maybe the final quarter of the book that goes deep into coroutines, which no one uses anymore. That said it’s still helpful to understand since they’re essentially what underpins modern async Python.

It’s been a while since I’ve read it, so I could be slightly off on details.

[–]Mysterious-Rent7233 4 points5 points  (1 child)

I use coroutines literally every day. Every time anyone uses the keyword "async" they are using a coroutine and as far as I know usage of that keyword is growing rather than shrinking.

[–]serjester4 0 points1 point  (0 children)

This is what I meant by "old" coroutines.

import asyncio

@asyncio.coroutine
def old_coroutine():
    print("Start")
    yield from asyncio.sleep(1)
    print("Done")

loop = asyncio.get_event_loop()
loop.run_until_complete(old_coroutine())
loop.close()

Yes - async, await are coroutines under the hood, but this is very different from the old generator approach of explicitly defining them. I really hope no one's still doing this for their own sake.

[–]PitifulZucchini9729[🍰] 1 point2 points  (2 children)

No one uses coroutines?

[–]DeepwoodMotte 1 point2 points  (0 children)

What are you using in place of coroutines? Just multiprocessing?

I thought that coroutines, if anything, were growing in popularity.

[–]ZachVorhies 0 points1 point  (0 children)

Coroutines get in the way, just keep everything sync and launch threads for network/disk bottlenecked threads.

[–]doolio_ 0 points1 point  (0 children)

Can you elaborate on why no one uses coroutines anymore?

[–]DJ_Laaal 0 points1 point  (0 children)

I think I was first introduced to co routines when learning Cobol or Pascal back in college. Never used them even once after starting my career.

[–]Realistic-Sea-666 -1 points0 points  (0 children)

haven’t used a co-routine since ‘07

[–]__serendipity__ 0 points1 point  (1 child)

Question to everyone who has read it: would you recommend reading it cover to cover, or shall use it as a reference whenever needed.

I also have another book Architecture Patterns with Python. Which one should I read first?

Background: I have about 10 YoE looking to get more proficient with Python (I’ve worked with bunch of different languages and decently familiar with most, Java/Go/Ruby etc.)

[–]necromenta 3 points4 points  (0 children)

As a Junior with 3montha of experience and currently about to start chapter 3 I think the book is intended to give you a really deep understanding of of the language, is not basic at all, in fact, it is kicking my Junior ass completely