On the Fediverse also as @mapto@qoto.org

Можете да намерите и като @mapto@masto.bg

Abito in Italia @mapto@feddit.it

  • 4 Posts
  • 35 Comments
Joined 10 months ago
cake
Cake day: January 12th, 2024

help-circle


  • Martín@lemmy.worldtoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    1 month ago

    It is not realistic to replicate a production setup in development when you’re working with sensitive user data. I’ve worked in different contexts (law enforcement, healthcare, financial services) where we’ve had complicated setups (in one instance including a thing called pre-staging environment), but never would a sizeable team of developers have access to user data, and thus to a realistic setup in terms of size, let alone of quality of data.













  • If you do that, nothing will actually be checked. You need to explicitly run pyright in CI.

    Are you suggesting that you prefer to do the type validation upon execution? I’d like to have the checks done beforehand, be it in the IDE during coding or in CI. This way the feedback loop is shorter.

    Then, backwards compatibility is a big thing in python, unlike node. So when typehints were introduced in 3.5 with PEP 484, they had to be optional.

    At least Typescript defines the semantics of its type hints. Python only defines the syntax! You can have multiple type checkers that conflict with each other!

    It is a bit more complicated than that. Here’s a quote the above-mentioned PEP (3.5 was back in 2015, we’re at 3.12 now and typehints have evolved):

    Note that this PEP still explicitly does NOT prevent other uses of annotations, nor does it require (or forbid) any particular processing of annotations, even when they conform to this specification. It simply enables better coordination, as PEP 333 did for web frameworks.

    https://peps.python.org/pep-0484/