Python dataclass gen wishlist

[kshefchek]

After working with the generated dataclasses a little, I have some suggestions for improvements, although these may not be desired or suitable for all users:

• Have all fields be optional and only enforce required fields when serializing the model

ie I want to be able to compose the model

gene_a = Gene()
gene_a.id = "foo:bar"

• Add validators to setters, such as constraining ids to curies and optionally specific curie prefixes when applicable. Currently validation only happens on initialization using post_init hooks.

• Some way to have a strict mode to enforce either a scalar or vector, currently there are a lot of Union[str, List[]] floating around which puts the burdens on clients to type check the values being built with these dataclasses.

[hsolbrig]

I wholeheartedly agree w/ the first statement -- the scalar vector things may need a bit more discussion, as sometimes it has been handy to auto convert a scalar into a vector, but we need a consistent philosophy. Can we start a discussion section on this?

[kshefchek]

I think this makes sense for certain things that are more likely to be lists of 1 item, like provided_by. But I'm curious where the auto conversion would occur. It could occur on the dataclass itself. But thinking about consuming these as json on the javascript side, it's more convenient knowing if a field is a list (and in the null case an empty list).

[cmungall]

Great suggestions kent! Anyone want to make the case gor immutable objects? Harold are you suggesting the new github discussions feature? I havent tried that yet

…

On Wed, Jan 6, 2021, 13:15 Harold Solbrig ***@***.***> wrote: I wholeheartedly agree w/ the first statement -- the scalar vector things may need a bit more discussion, as sometimes it has been handy to auto convert a scalar into a vector, but we need a consistent philosophy. Can we start a discussion section on this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/biolink/biolinkml/discussions/327#discussioncomment-265691>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOODKNFLNO75WQQJ5G3SYTHFXANCNFSM4VX3DHFA> .

[hsolbrig]

Not sure how it happened, but this is a self-reference (https://github.com/biolink/biolinkml/discussions/327)

[hsolbrig]

Earlier versions of BiolinkML had a global strict setting that was intended to meet at least some of the requirements above. At the time it didn't have a real world use case, so we abandoned it. It wouldn't be too hard to restore, especially given that we no longer use dataclass to enforce required fields.

I'd propose we put together a short spec on what we need to have happen. Volunteers?

[hsolbrig]

WRT Immutable Objects -- the enums addition includes a variant of that if I understand what is being asked.

[kshefchek]

Another annoyance of dataclasses is that you can add arbitrary attributes after creating an object (unless Frozen=True) is set.

should we consider something like dataclasses + pydantic?

edit: looks like pydantic does not support checking this either, so disregard!

[hsolbrig]

To the best of my knowledge, the code that we've got that uses dataclasses prevents the addition of arbitrary attributes.

It might be useful to create some test cases that show where the current behavior isn't what is desired -- it would give us something concrete to focus on.

[kshefchek]

I've prototyped a pydantic generator to fill some of these use cases. I would be interested in others thoughts

code - https://github.com/monarch-initiative/koza/blob/main/scripts/pydanticgen.py
model.py - https://github.com/monarch-initiative/koza/blob/main/koza/model/biolink/model.py

[cmungall]

I believe this is now supported in pydanticgen