> Previously, the only way to add a dialect was through register_dialect
that does

>  > type checking to make sure it gets a legit dialect object. Now, the
> _dialects dict is
> > directly accessible to Python code and it can add arbitrary objects to
> it (both as
> > keys and as values). Does this mean that the C code now has to do type
> checking in all
> > internal code that accesses _dialects?
>
> You are right, I forgot about that part. That will make the patch
> significantly more complicated.
>

:-/

Turns out there's real merit in having a clear dividing line between the
safe world of Python and unsafe world of C. Within the C code, some
invariants are assumed to be correct (and can be efficiently assert()-ed) -
this makes the code simpler and more performant.

> > However, it's a step in the right direction in case we do have multiple
> instances of
> > the extension module alive at the same time in the future. Although then
> it would be
> > interesting to consider how to find the actually correct module instance
> from internal
> > functions.
>
> This sounds basically impossible (which is why we *can't* have multiple
> instances of an extension module alive in a single interpreter :-)).
>

Well, it surely isn't possible without significant code rewriting. But I
can envision carrying such "state" around in extension-specific objects.
Although it's not entirely clear whether the memory cost is justified.

But without it, it's not clear to me how we plan to have multiple living
extension modules at all. Perhaps this is a discussion outside this
specific issue though (maybe for the PEP Stefan writes)