I'm working on a web spider using Python 3.14 with free threading, and I've noticed that there's no locking when multiple threads operate on the `all_stories` list. Can anyone tell me if using `list.extend` in this context is thread-safe? Here is a snippet of the code:
```python
async def worker(queue: Queue, all_stories: list) -> None:
async with aiohttp.ClientSession() as session:
while True:
async with asyncio.TaskGroup() as tg:
try:
page = queue.get(block=False)
except Empty:
break
html = await fetch(session, page)
stories = parse_stories(html)
if not stories:
break
all_stories.extend(stories)
```
3 Answers
Yes, `list.extend` is considered thread-safe in Python 3.14, even with free threading. This means that while multiple threads can use `extend`, it doesn’t guarantee operations won't interfere. So keep that in mind!
So just to clarify, you're saying it's safe in a sense, but not atomic, right?
You're asking a very nuanced question! So, `list.extend` is thread-safe in Python 3.14, but it's not atomic. This means if you have multiple threads running, you can have interference leading to unexpected results. To illustrate, if one thread is extending the list, another could modify it at the same time, causing issues. Also, remember all async code typically runs in a single thread within an event loop, so multithreading concerns might not really apply unless you explicitly introduce threads into your asynchronous code.
There’s a distinction here. While `list.extend` isn't atomic and can release the GIL, it works within the confines of the GIL’s behavior. If you're running async tasks, they won’t slice in while `extend` is being executed unless there are parallel threads, which can complicate things. Just be cautious and consider potential race conditions when dealing with shared lists!
Wait, are you saying it’s actually atomic? I'm not sure if that's true for all versions. Is there any official documentation that backs this up?