It tracks "conflicts" at mutable boundaries, building: 1. A "shadow stack" recording when values are assigned to objects which are referenced from more than one thread. 2. A finer-grained model of SQL and Redis items that take into account some of the semantics of their concurrency models.
The code executes normally once, to get conflict points, then it uses a version of an algorithm called Dynamic Partial Order Reduction (DPOR) to efficiently search through all non-isomorphic traces looking for failures (either a crash, a statically detected deadlock, or a violation of the property/invariant provided in the test). This was partially inspired by the rust concurrency testing library Loom, though uses monkey-patching instead of customer concurrency primitives.
https://github.com/lucaswiman/frontrun
Hi HN, I'm the author of Frontrun, a Python concurrency testing library I built over the past 6 months using Claude Code and Codex. It uses bytecode tracing and various forms of monkeypatching to schedule across threads, async and multiprocessing allowing you to find and deterministically reproduce race conditions or deadlocks.It can understand Python variable assignments, SQL statements and...
It was a design goal of free-threading that any race condition which can occur in pure python code without the GIL must have already been possible on the same code with the GIL. To achieve that, they added various locks which fix cpython primitive operations that were only threadsafe because of the GIL. That's why single-threaded execution is slower without the GIL.
However, it's possible there were races which were very unlikely with the GIL that are much more likely now, e.g. one requiring multiple context switches in evaluating a single statement like `a.b = c[a.b].d()`. With the GIL, that might require multiple operations in that assignment taking >5ms. If all those operations are fast might almost never come up, but without the GIL, a different thread could mutate a.b as often as it wants.
I haven't heard of this coming up in practice, but it's certainly something that could in principle happen. The amount of FUD about it in every discussion about python finally making progress on threading seems excessive though.
Akasa is a healthcare automation company, pioneering "Unified Automation" that seamlessly integrates machine learning, human domain experts and traditional software automation into healthcare workflows for revenue cycle management and other areas. We combine deep domain knowledge of healthcare revenue cycle management with innovative technology. We have contracts with some of the largest healthcare providers in the US and are growing quickly.
We're currently hiring for several roles in machine learning, security/infrastructure and our automation platform. We're also hiring in implementation engineering positions that can provide a good career path to level up on software engineering. https://akasa.com/careers/
That said, having started on updating that same codebase to Python 3, the Django team tries hard to provide the KEY thing you need to seamlessly update a codebase: a version which can support both incompatible features. Without this, you need to have one giant branch with a bunch of renames and other changes. They actually introduce deprecation warnings, and have something non-deprecated you can use in the same version. I think if Python core had introduced a version of Python including both versions of all the module renames with deprecation warnings, the community would be much further along on the upgrade path.
It's clearly explained code that's shorter than you would have thought. Norvig showcases his expertise in manipulating both the basic data structure of the Python language, and a deep understanding of the underlying problem and methods for solving it.
Thanks for the links! These look extremely helpful!
I think Prolog rules can replace a lot of spaghetti code: stuff like "Usually do this, but then other times do this, unless this other thing is true. If there's a parse error, then do xyz and keep going." In ordinary procedural code, the exception cases can dominate the body of a function and may need to be deeply nested, but in Prolog, it's possible to cordon them off or express them at the top level.
I suspect it might be most useful as a DSL you can embed inside of other languages, though I haven't seen a good implementation of that. (The clojure core.logic library mentioned elsewhere looks really promising.)
I think it may also be useful for domain experts to specify simple rules that capture an aspect of their expertise. If you restrict the domain down enough, and work to figure out what predicates are needed, prolog rules can become easy enough to read that you don't need to know much programming to use them. But the devil seems to be in the details of connecting the core logic into a bigger system that actually does something.
For example, the answer for hooking prolog up to a SQL database is "Look at the ODBC library!", which is not a very satisfactory answer. I think you could build a really beautiful ORM system in Prolog, but nobody's done it yet. (Maybe ORM isn't the right phrase, but a clean way of relating prolog queries to database queries and vice versa.)
The syntax is wonderfully simple, but also has almost no sugar for common idioms. The predicate notation makes it somewhat harder to batch up a bunch of attributes into one conceptual "thing" than in other languages. That means you need to keep positional arguments in your head a lot more. I think aping the class constructor and attribute notation of other languages would be helpful like `my_foo(foo, bar:attr, baz:attr) :- [...].` Then you could reference that either as a constructor (`my_foo(a,b,c)` would state that `a.bar=b` and `a.baz=c`) or to generate goals, like `my_foo(foo), other_predicate(foo.bar)`. Prolog is so old that choices like "make '.' the end of a statement" made sense at the time, but haven't stood the test of history.
(Disclaimer: Many of my criticisms may have perfectly valid solutions in prolog. I'm still learning it.)