fastcore v2: Python utilities for AI inference, now with a cleaner API

What fastcore solves for AI inference

fastcore is a Python utility library from AnswerDotAI, the company behind fast.ai. It is not an inference engine itself. It provides the plumbing that makes inference code shorter and more reliable. The README describes it as adding features inspired by Ruby and Haskell, plus missing pieces from the standard library. For AI inference, the relevant parts are the enhanced list type L, the async helpers in fastcore.aio, and the simplified thread and process pools. The target user is an engineer writing local experimentation scripts or runtime orchestration code who wants to avoid repeating boilerplate. The library is designed so you can do `from fastcore.module import *` without polluting your namespace, which is unusual and convenient for notebooks.

The v2 API break and what changed

The July 2026 v2 release is a deliberate cleanup. The README lists breaking changes, and they are significant. Param is gone from fastcore.script; you now use plain type annotations with docments, or typing.Annotated[type, "help"], optionally with a dict of argparse arguments. The L methods starmap, starfilter, and the other star* and rstar* methods are replaced by the star and rstar function adapters, which compose with every L method, e.g. t.map(star(f)). spread is replaced by star, and dspread is renamed to dstar. Async helpers moved from net and xtras into a new fastcore.aio module. The Config class and config file functions moved from foundation to xtras. fastcore.net lost its request builders: urlrequest, urlsend, do_request, urlcheck. clean_type_str is gone. parallel_gen is removed; the stdlib ProcessPoolExecutor initializer pattern replaces it. Python 3.11 or later is required. The README says that if you use `from fastcore.utils import *` or fastcore.all, most changes won't affect you, but that is a promise you should verify against your own code.

How the core mechanisms work

The central mechanism is the L class, a drop-in replacement for list. The README shows that L supports indexing with a collection, mapping, filtering, and unique, all in a chained style. For example, x[[0,3]] returns [1,4], and x.map(lambda o:o*2) returns [2,4,6,8]. This is not a new concept, but L adds method chaining and advanced indexing that plain list lacks. The @patch decorator lets you add methods to existing classes, including built-ins, without subclassing. store_attr() in __init__ sets multiple attributes from arguments, reducing repetitive assignment. The delegates decorator replaces **kwargs with explicit parameters, which improves IDE support. For parallel work, fastcore provides enhanced ThreadPoolExecutor and ProcessPoolExecutor. The README does not give examples of these, so the exact API is not shown, but the description is clear: simplified concurrent processing.

Getting fastcore running

Installation is straightforward. The README gives two options: `conda install fastcore -c fastai` for Anaconda, or `pip install fastcore`. For an editable install, clone the repo and run `pip install -e ".[dev]"`. The library is tested on Ubuntu, macOS, and Windows. The README does not mention any special configuration or environment variables. After installation, you can import with `from fastcore.module import *` or `import fastcore.all`. The docs recommend liberal imports, which is unusual but safe because the library is designed for wildcard imports. For CLI creation, the README says to use fastcore.script, but the v2 change means you should not use Param. The README points to docments and typing.Annotated as the replacement, but it does not show a full example.

Where fastcore is the wrong tool

The most obvious limitation is the Python version requirement. Python 3.11 or later is mandatory in v2. If you are stuck on Python 3.10 or earlier, you cannot use v2 at all. The README suggests pinning fastcore<2 if you need the old APIs, but that means you lose future updates. Another limitation is the API churn. The v2 release removed several features that had 'accumulated better alternatives', but that is a judgement call. If you relied on parallel_gen or the request builders in fastcore.net, you have to rewrite that code. The README says the stdlib ProcessPoolExecutor initializer pattern replaces parallel_gen, but that is a pattern you must implement yourself; fastcore no longer provides the helper. For a library whose selling point is reducing boilerplate, removing a parallel helper and telling you to use the stdlib pattern is a step back in convenience. Also, fastcore is not an inference framework. It does not load models, handle GPU memory, or manage requests. It is a utility layer, and if you need those things, you need other tools.

Alternatives and how they differ

The closest alternative is the Python standard library itself. For list operations, you can use list comprehensions and itertools. For async, you have asyncio. For parallel execution, you have concurrent.futures. The difference is that fastcore wraps these with a more concise, chainable API. For example, L.map and L.filter replace explicit loops or generator expressions. The README's example x.map(lambda o:o*2) is equivalent to [o*2 for o in x]. The delegates decorator is similar to functools.wraps but adds explicit parameter forwarding. Another alternative is toolz, a functional programming library that provides compose, curry, and other utilities. toolz does not have the @patch decorator or store_attr. The key difference is that fastcore is designed for the fast.ai ecosystem and its style of notebook-heavy development, while toolz is more general. If you are not using fast.ai or AnswerDotAI's other libraries, you might find the API style unusual.

Maintenance and license considerations

fastcore is licensed under Apache-2.0, which is permissive and allows commercial use, modification, and redistribution, with the requirement to include the original copyright notice. The repository is actively maintained, with the last push on August 26, 2026, and three releases in four days: v2.2.16, v2.2.15, and v2.2.14. That release cadence indicates active development, but it also means the API could change again. The README notes that the file is autogenerated, and the project uses a documentation system that generates docs from code, so you should expect frequent updates. The v2 release is a major version, and the README explicitly lists breaking changes, so the maintainers are aware of the migration burden. For an engineer, the maintenance cost is the time to update code when such breaks happen. The README says pinning fastcore<2 is an option if you need the old APIs, but that is a temporary fix. The project's documentation site is fastcore.fast.ai, which is a stable reference.

What to verify before adopting

Before you adopt fastcore v2, verify that your Python environment is 3.11 or later. Check your existing code for the removed APIs: Param, star*, spread, dspread, parallel_gen, and the fastcore.net request builders. The README gives replacements for each, but you need to confirm they work in your context. If you use fastcore.utils or fastcore.all, the README says most changes won't affect you, but that is a general statement; you should run your test suite after upgrading. Also verify that your IDE and tooling handle the delegates decorator correctly, since the README claims improved IDE support. The library is tested on Ubuntu, macOS, and Windows, but the README does not specify which versions, so test on your target OS. Finally, if you are using fastcore in a production inference service, check that the async helpers in fastcore.aio behave as expected under load, since the README does not provide benchmarks or examples of error handling.

Editorial conclusion

Adopt fastcore v2 if you are building AI inference pipelines in Python 3.11+ and want a single library for list operations, async helpers, and parallel execution. Skip it if you prefer minimal dependencies or need Python 3.10 or earlier. Before adopting, verify that your current code does not rely on the removed APIs: Param from fastcore.script, the star* methods on L, parallel_gen, or the request builders in fastcore.net. If you do, pin fastcore<2 until you migrate. The v2 API is a deliberate break, and the README lists the replacements, so the migration path is concrete.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes