Frank Dana

OK, so now we have performance numbers for all six platforms under Python 3.13. (Three OSes, with and without freethreading.) ## Linux ### Python 3.13 (with GIL) ```text ------------------------------------------ benchmark...

It's... "impressive"? how much slower the freethreaded interpreter is when you're _not_ making use of its features. Our non-thread-safe parser code runs almost _twice_ as slow, on Linux, as it...

And, now we know: Pydot runtimes (average) to parse every file in our `test/graphs/` directory: | | Python 3.13 | Python 3.13t | |-------------|-------------|--------------| | **Linux** | 31.6s | 50s...

This Pr is gonna get hosed by the 100%-coverage PR anyway, I'll wait until that's merged and then fix up this one.

Yeah, that shared fixture is still messing up the parallel test runs. I should probably just mark that test as `thread_unsafe`, rather than struggling to make Pytest's fixture mechanism thread-safe...

> I'm hoping nobody is relying on the current broken behaviour, though. Like: > > * They create a graph > * Add multiple instances of the same node "x"...

Now, granted, if your only goal is to generate `dot` syntax and you don't care about the API representation of the graph, that does work fine. Continuing from the above:...

One solution might be to _get rid_ of `.set_name()` and make the node's name immutable. Since we don't have any code for actually _handling_ a name-change properly, allowing them to...

I've also wondered, semi-related: Should our .set_foo() methods return the updated node, instead of `None`? Or, alternately, should we have .with_foo() methods that return a _copy_ of the node with...

I should look at how GraphViz handles this internally. Obviously they don't have to deal with things like deletions, which makes life a _lot_ easier. But, still, their processing of...