Jacob Walls

Related: a proposal in archesproject/arches-querysets#25 that would have datatypes "declare" via a SQL fragment how to extract display values from tile data.

> I do wonder if this warrants the API change. Yeah, I'm reluctant to add an early transforms API for this. We should consider alternatives: - in _register_require_version(): manipulate sys.modules...

Of course! When you return to this, please remember to add Simon as co-author 👍

We're now skipping these tests on 3.14+, thanks all!

May I ask what version of Arches? TileCardinalityError has a different MRO in v8, see #11804

Thanks, we have a major class of bugs in pylint where by habit we default to `safe_infer()` instead of `infer_all()`. cc/ @Pierre-Sassoulas @mbyrnepr2 @zenlyj for awareness during triage.

I mean, should this be configurable with `--strict` mode?

My thought is that brain_dataclasses.py should be catching `MroError` when it calls `.mro()`. That's the pattern I see elsewhere.

That seems fine to me. This is an edge case, no? And there are other errors that subclass MroError we should catch also, I think.

I don't know yet. I'm planning to take a look this week.