3 ms·

This is true, there is a performance cost Apart from what has been said, I find pydantic interesting even in the middle of my code: it can be seen as an overpo

This is true, there is a performance cost 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)

codethief 1y ago
You could also use a TypedDict for that, though? PEP 764[0] will make them extra convenient. [0]: https://peps.python.org/pep-0764/ https://peps.python.org/pep-0764/
- JackSlateur 1y ago
  Typing is declarative 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'}
  - codethief 1y ago
    Rolls eyes… Of course you need to use a type checker. Who doesn't these days?
    - JackSlateur 1y ago
      Of course, I need runtime validation
      - codethief 1y ago
        Sure, runtime validation is useful – at the boundaries of your domain! After that your type checker should ensure your data has the shape your code expects. In other words: Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
        JackSlateur 1y ago
        Yes 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)
duncanfwalker 1y ago
Yeah, I'd agree with that. Validation rules are like an extension to the type system. Invariants are useful at the edges of a system but also in the core. If, for example, I can be told that a list is non-empty then I can write more clean code to handle it. 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'.

codethief 1y ago

You could also use a TypedDict for that, though? PEP 764[0] will make them extra convenient. [0]: https://peps.python.org/pep-0764/ https://peps.python.org/pep-0764/

JackSlateur 1y ago
Typing is declarative 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'}
- codethief 1y ago
  Rolls eyes… Of course you need to use a type checker. Who doesn't these days?
  - JackSlateur 1y ago
    Of course, I need runtime validation
    - codethief 1y ago
      Sure, runtime validation is useful – at the boundaries of your domain! After that your type checker should ensure your data has the shape your code expects. In other words: Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
      - JackSlateur 1y ago
        Yes 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)

duncanfwalker 1y ago

Yeah, I'd agree with that. Validation rules are like an extension to the type system. Invariants are useful at the edges of a system but also in the core. If, for example, I can be told that a list is non-empty then I can write more clean code to handle it. 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'.