Why can't a Literal string value be used to override a str?

[awgymer]

I have a pydantic model which has a string field:

class MyBase(BaseModel)
    a: str

If I try and create a subclass which should have a specific string (or set of strings) I get an error:

class MySpecific(MyBase):
    a: Literal['KEY']

>>> Override type "Literal['KEY']" is not the same as base type "str"

But to me Literal['KEY'] is as string? So what is the reasoning behind this error and is there a better way to solve this?

[erictraut]

Literal['KEY'] is a subtype of str, but they are not equivalent types. The a field is mutable, so subclasses of MyBase cannot safely override its type with a subtype of the base attribute's type. This can lead to errors if MySpecific is upcast to MyBase and then someone writes a str value to a that is not compatible with Literal['KEY'].

If you want to override a with a subtype in a type-safe manner, the attribute must be immutable in the base class. For example, if you were to define the model as frozen, its attributes would be considered immutable.

[awgymer]

Apologies I'm not sure I understand what you mean here about upcasting to the parent class?

The Literal here is really just a way of defining the allowed set of strings, without needing to reimplement a validator method on each subclass (or using an enum) because the idea was that the base class would simply have no restriction other than being a string.

Maybe I have to make this a generic field or perhaps revert to using a validator

[erictraut]

from typing import Literal
from pydantic import BaseModel

class MyBase(BaseModel):
    a: str

class MySpecific(MyBase):
    a: Literal["KEY"]

def mutate_base(x: MyBase):
    x.a = "not KEY"

v = MySpecific(a="KEY")
mutate_base(v) # v is upcast to `MyBase` when making this call

assert v.a == "KEY"  # Assertion fails!

[awgymer]

Hmm I guess I see the issue with that. Except that in reality Literal['KEY'] can of course be mutated regardless. I suppose this is a case where the validation method should handle this.

Or would this not be an issue if the class was frozen?