Discussion: handle recursion? about polyfactory

[lindycoder]

If this was

class A(BaseModel):
    b: "B"

class B(BaseModel):
    a: A

It would be downright impossible do instantiate this anyway... so "true" recursion is really possible unless there's an "out".

In the example you have, the "out" is the "empty list" in the example from the startlite bug, the "out" is a None on the subentity.

My recommendation would be that anything that can be empty is empty unless specified otherwise, and everything Optional[] is None, unless specified otherwise.

I know this would break the current behaviour and people might rely on this behaviour that sometimes Optional stuff is None and dict/list have 1 element and sets have a lot of letters.

For the record, i personally do make my ModelFactories have a Use(list) or similar for any "emptyable" field. My philosophy is that worst case should be handled, and if you NEED a value in there it's because you're testing what happens with it, so might as well define it clearly in your test :)

A backward compatible option could be a way to turn this ModelFactory into a "pessimist" mode that would do what I do making stuff empty or None, which could resolve these recursive references.

[Goldziher]

We should aim for backward compatible solutions. I'm thinking if the pessimistic setting etc.

Do you feel like implementing this?

[roeeyn]

So how should we handle the provided example then?

[Goldziher]

So how should we handle the provided example then?

I think to add a max recursion value to a factory with a default. Upon identifying more than the max recursion, switch the value to none, if it's optional, otherwise raise a verbose error with user instructions