Prompting: response_model | schema does not work with Enum

[mondaychen]

class Armor(str, Enum):
    leather = "leather"
    chainmail = "chainmail"
    plate = "plate"

class Character(BaseModel):
    """
    A character in a fantasy world.
    """
    name: constr(max_length=12)
    armor: Armor
    strength: int

@text.prompt
def ppt(response_model):
    """Make A character in a fantasy world.

    RESPONSE FORMAT:
    {{ response_model | schema }}
    """

print(ppt(Character))

Get error KeyError: 'properties'

If remove armor from Character this works fine

[rlouf]

Thanks! Feel free to open a PR to fix this, it shouldn't be a big change to the current logic.

[brandonwillard]

It looks like this is a feature request for Enum and constr prompts, and it's not entirely clear to me how we should translate those to prompts. Do we want them to take their JSON schema formats?

[LeoGrosjean]

Hey guys, I'm about to rewrite text.prompts.parse_pydantic_schema

Based on :

class JokeType(str, Enum):
    dark = "dark"
    light = "light"

class Joke(BaseModel):
    joke: str
    type: JokeType = Field(..., description="description_value")
    explanation: str

@text.prompt
def prompt_func(response_model):
    """Make a joke about c++.

    RESPONSE FORMAT:
    {{ response_model | schema }}
    """

prompt = prompt_func(Joke)
#Make a joke about c++.
#RESPONSE FORMAT:
#{
#  "joke": "<joke>",
#  "type": "description_value",
#  "explanation": "<explanation>"
#}

But I have few questions of improvements, do you have a topic where you decided how "<value>" should be displayed ?

1. Do we want to keep Optional[Any] fields ?

   we can loop on required

   1. What about fields with default values ? should user don't use it ?

2. iterable display : "<[value1, ..., value_n]>"

3. constr : should we display "<value | **constr_kwarg>"

   could pop title and type Need to check nested ones to be sure, but could pop also "required" values

4. add type ? "<value | type>"

   handle primitive or most used/adopt by python community only

5. add description Field(..., description='my custom description) -> "<value | description>"

6. handle Validator and transcribe into description

   use transformer to explain the code within ? might be dangerous

Values will look like this in the prompt : "<value | type | **constr_kwargs & description>"

What about it, if you have ideas or no go, let me know