7 ms·

as a reminder for yourself/others who need to read/maintain your code? (I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is

• the_af 5y ago
  So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).
  • zokier 5y ago
    yes, and yes. and they are still useful.
  • rglullis 5y ago
    You can have mypy doing the type checking. Just put it on your CI pipeline alongside your tests.
    • the_af 5y ago
      I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.
      • rglullis 5y ago
        Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.
        • the_af 5y ago
          You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't. This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though. > If you/your team want to use a statically typed language, then use one. Python is not it. This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
          • TillE 5y ago
            Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
            • the_af 5y ago
              Fair enough. I can see how my statement was not very clear. I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them. Also, let me restate we cannot pick the language. We can just make better or worse use of it.
          • rglullis 5y ago
  • xarope 5y ago
    it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)
    • the_af 5y ago
      Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking. If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).
      • dragonwriter 5y ago
        They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.
        • the_af 5y ago
          Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it. I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.
  • dragonwriter 5y ago
    > So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.
    • the_af 5y ago
      As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool. In my opinion, of course.