Support defaults from Pydantic fields

[jinnovation]

Contributes to #793.

This PR implements quick-and-dirty support for Pydantic-style default values. In other words, the following two classes will render equivalently:

class Foo(pydantic.BaseModel):
    """Foo class documentation."""

    a: int = pydantic.Field(default=1, description="Docstring for a")

class Foo(pydantic.BaseModel):
    """Foo class documentation."""

    a: int = 1
    """Docstring for a"""

Open questions:

• Should Pydantic support for pdoc be split out into a separate "plugin" package, e.g. pdoc-pydantic or pdoc[pydantic]?
• Is this the best place for default-value-extraction logic for Pydantic classes to live?

[mhils]

Thanks!

Should Pydantic support for pdoc be split out into a separate "plugin" package, e.g. pdoc-pydantic or pdoc[pydantic]?

Too much complexity for now. I think pydantic is popular enough to have support for it builtin for now.

Is this the best place for default-value-extraction logic for Pydantic classes to live?

Pragmatically yes. See my comments below on how we can keep things reasonably clean.

[jinnovation]

Two issues related to rendering Pydantic model docs that I propose treating as out-of-scope for this PR:

• If user's BaseModel subclass does not have its own class-level docstring, we end up rendering the docs for BaseModel itself;
• We render the docs for model_config, which is typically only useful to implementers of the class and not to users thereof, i.e. the expected audience for the generated docs

[jinnovation]

@mhils: Let me know what you think of this approach. It kind of contradicts the precedent members() sets of deferring all filtering/exclusion logic to the downstream templates.

[mhils]

I think it's not the end of the world, but we could maybe move it into Class._member_objects? That already has some special cases for constructors. Adding another special case for pydantic there makes more sense maybe.

[mhils]

Thank you! This looks great overall. Mostly some minor stylistic nits.

[mhils]

I think it's not the end of the world, but we could maybe move it into Class._member_objects? That already has some special cases for constructors. Adding another special case for pydantic there makes more sense maybe.

[mhils]

This does not seem to be working yet? :)

[jinnovation]

🤨 could swear this was working before.

Either way, will look into. Moving this back to draft.

[jinnovation]

Oh, I'm trying to do two things at once. (:

This PR started off just handling Pydantic default values, but I've since expanded scope to also include descriptions.

Will revise PR title + description + all that before opening back up for review.

[jinnovation]

Consolidate conditional logic into _pydantic like w/ default_value().