Apart from what has been said, I find pydantic interesting even in the middle of my code: it can be seen as an overpowered assert
It helps making sure that the complex data structure returned by that method is valid (for instance)
Apart from what has been said, I find pydantic interesting even in the middle of my code: it can be seen as an overpowered assert
It helps making sure that the complex data structure returned by that method is valid (for instance)
In Java they got around the external-dependency-in-the-core-model problem by making the JSR-380 specification that could (even if only in theory) have multiple implementations.
In clojure you don't need to worry about another external dependency because the spec library is built-in. One could argue that it's still a dependency even if it's coming from the standard library. At the point I'd say, why are we worried about this? it's to isolate our core from unnecessary reasons to change.
I get that principled terms it's not right but, if those libraries change on API on a similar cadence to the programming language syntax, then it doesn't impact in practical terms. It's these kind of pragmatic compromises that distinguish Python from Java - after all, 'worse is better'.
PEP 764[0] will make them extra convenient.
In the end, it ensures nothing and accepts everything
$ cat test.py
from typing import TypedDict
class MyDict(TypedDict):
some_bool: bool
print(MyDict(some_bool="test", unknown_field="blabla"))
=> $ ./test.py
{'some_bool': 'test', 'unknown_field': 'blabla'}In other words: Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
The boundaries of my domain is everywhere, because stuff are built everywhere. I'm sure I am a bad dev, yet prebuilding all possibles objects I might need everytime I receive an input sounds stupid at best
(btw, this post sounds a lot like "if it compiles, it works", not gonna do this, especially in Python)