I started programming in Rust several years ago, and it has gradually changed the way I design programs in other programming languages, most notably in Python. Before I started using Rust, I was usually writing Python code in a very dynamic and type-loose way, without type hints, passing and returning dictionaries everywhere, and occasionally falling back to “stringly-typed” interfaces. However, after experiencing the strictness of the Rust type system, and noticing all the problems that it prevents “by construction”, I suddenly became quite anxious whenever I got back to Python and wasn’t provided with the same guarantees.

One of my fav Python writeups. I love Python and luckily I get to dictate how it’s being written in my job, so I’m forcing types down the through of my colleagues. Saved a bunch of debugging time, so I can waste more time on Lemmy while still getting paid. Good shit

    • im_orange@discuss.tchncs.deEnglish
      3·
      1 year ago

      Oh my gosh… This project and its readme are amazing. I gotta try this at work tomorrow, I hope my co-workers can bear with me.

      Edit: I just found the release notes… I love it

    • mwguy@infosec.pub
      2·
      1 year ago

      Thanks for this. I might start to use this. This would allow me to add typing class or function at a time and slowly work my way back.

  • bill_1992@lemmy.world
    9·
    1 year ago

    I had a mixed experience adding types to a large enterprise Python codebase.

    I think the thing that really kills it is the (relative) lack of community support. Whereas with TS, almost every package big or small usually has types, I’ve found a lot of pip packages wouldn’t be typed out of the box, which means you gotta generate them automatically or use escape hatches like Any.

    Using escape hatches like Any basically kill the point of typing, as the static checker basically stops checking after it sees an Any. If your static checker is configured to ignore certain files because they aren’t typed yet, then any code that refers to those files also get ignored. You basically need to hit a threshold of your codebase and dependencies to get the benefits of typing. Until then, my experience was finding bugs that the type checker should’ve caught but didn’t.

    And obviously, to get the full power of types, you must buy in as a team, and that means really buy-in, without resorting to escape hatches like Any. Any reluctance, and you’re likely in for an uphill battle.

    Another thing that really hurt adoption, was that before using typing, a lot of the code just clearly broke type rules, eg a function that returns a string or a number, but the caller assumes the output is a number. Especially if it’s lower level code, those may take a nontrivial refactor to fix.

    All of this is assuming it’s trivial to enforce a static check on the codebase through CI/CD.

    This leads to my conclusion, that not being forced to use types is a BENEFIT of Python, not a downside. You are able to write code a lot faster and more expressively if you don’t need to worry about typing, for small scripts or whatnot. I think if you’re starting a project of any size and already know you want typing, consider using another language that has typing built in.

  • xurxia@mander.xyz
    9·
    1 year ago

    I fully agree with the post. Except for a fast prototyping or a short personal script where it could be not necessary, type hint is a must. The subject is not only to guarantee that the program now runs without errors, but it will be still working right in the future too, even after a developer (either the original or other) make changes to the code.

  • vzq@lemmy.world
    1·
    1 year ago

    My main issue is that you’re going through all that trouble and still get Python-level performance.

    I really like Python, but there are better typed languages out there. Also, faster ones.