Are you sure this should be object? I don't think toml can dump all objects.

From what I can see of the implementation, and from trying it, if it doesn't specifically handle an object it just stringifies it.

>>> TomlEncoder().dump_inline_table(object()) 
'"<object object at 0x000001FF99FF85A0>"'
>>> TomlEncoder().dump_value(object())        
'"<object object at 0x000001FF99FF85A0>"'
>>> TomlEncoder().dump_value(dict())   
'[]'
>>> TomlEncoder().dump_value([object()]) 
'[ "<object object at 0x000001FF99FF85A0>",]'
>>> TomlEncoder().dump_inline_table([object()]) 
'[ "<object object at 0x000001FF99FF85B0>",]'
>>> TomlEncoder().dump_inline_table({"aaa": object()}) 
'{ aaa = "<object object at 0x000001FF99FF85A0>" }\n'
>>> TomlEncoder().dump_value({"aaa": object()})        
'[ "aaa",]'

While technically it can handle all objects, in that it doesn't throw an exception, not all objects are correct arguments. "<object object at 0x000001FF99FF85B0>" is obviously not useful as an output.

And trying to represent intended values, we kindof hit the same issue as JSON.
There's also classes with custom repr that can be dumped.
And subclassed Encoder that extend dump_funcs to support more intended types.

To be consistent though, how about the dump_list method typed with Iterable[object] ? I feel the same logic should apply and be Iterable[Any]. (it's calling dump_value internally)

That's why Any makes sense here: the type annotation we'd ideally want isn't representable in the type system.

This kind of looks like it's using the | Any trick for when the type is almost always one particular type (like we do for re.match). If so, Any is right.

Those attributes are directly assigned from the parameters, so they should be the same.
If it's possible, and intended to be anything else than Mark | None, with an arbitrary type, or if it's to avoid having to check for a None mark when you know you instantiated it not-None. And that's a common use-case/pattern. That can be represented using generics. Since it's feasible within the current typing system, Incomplete (could be done but we didn't bothered) seems preferable over Any (can't be done, we tried)

I think there's an argument to be made here for either permissive unions or default generics. Which both aren't part of the type system atm. I've changed the type to Mark | None | AnyMark | Any and added a comment to explain.