Explanation: Python is a programming language. Numpy is a library for python that makes it possible to run large computations much faster than in native python. In order to make that possible, it needs to keep its own set of data types that are different from python’s native datatypes, which means you now have two different bool types and two different sets of True and False. Lovely.

Mypy is a type checker for python (python supports static typing, but doesn’t actually enforce it). Mypy treats numpy’s bool_ and python’s native bool as incompatible types, leading to the asinine error message above. Mypy is “technically” correct, since they are two completely different classes. But in practice, there is little functional difference between bool and bool_. So you have to do dumb workarounds like declaring every bool values as bool | np.bool_ or casting bool_ down to bool. Ugh. Both numpy and mypy declared this issue a WONTFIX. Lovely.

  • Daniel Quinn@lemmy.ca
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    7 months ago

    Honestly, after having served on a Very Large Project with Mypy everywhere, I can categorically say that I hate it. Types are great, type checking is great, but applying it to a language designed without types in mind is a recipe for pain.

    • folkrav@lemmy.ca
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      Adding types on an untyped project is hell. Greenfield stuff is usually pretty smooth sailing as far as I’m concerned…

  • Telorand@reddthat.com
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    7 months ago

    bool_ via Numpy is its own object, and it’s fundamentally different from bool in Python (which is itself a subclass of int, whereas bool_ is not).

    They are used similarly, but they’re similar in the same way a fork and a spork can both be used to eat spaghetti.

    • jubilationtcornpone@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 months ago

      I currently work on a NodeJS/React project and apparently I’m going to have to start pasting “‘any’ is not an acceptable return or parameter type” into every damned PR because half the crazy kids who started programming in JavaScript don’t seem to get it.

      For fucks sake, we have TypeScript for a reason. Use it!

      • magz :3@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        if you have a pipeline running eslint on all your PRs (which you should have!), you can set no-explicit-any as an error in your eslint config so it’s impossible to merge code with any in it

  • nickwitha_k (he/him)@lemmy.sdf.org
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    7 months ago

    Data typing is important. If two types do not have the same in-memory representation but you treat them like they do, you’re inviting a lot of potential bugs and security vulnerabilities to save a few characters.

    ETA: The WONTFIX is absolutely the correct response here. This would allow devs to shoot themselves in the foot for no real gain, eliminating the benefit of things like mypy. Type safety is your friend and will keep you from making simple mistakes.

    • owsei@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      Even if they do have the same in-memory representation, you may want to assert types as different just by name.

      AccountID: u64

      TransactionID: u64

      have the same in-memory representation, but are not interchangeable.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    7 months ago

    So you have to do dumb workarounds like declaring every bool values as bool | np.bool_ or casting bool_ down to bool.

    these dumb workarounds prevent you from shooting yourself on the foot and not allowing JS-level shit like "1" + 2 === "12"

    • guy@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      7 months ago

      "1" + 2 === "12" is not unique to JS (sans the requirement for the third equals sign), it’s a common feature of multiple strongly typed languages. imho it’s fine.

      EDIT: I did some testing:

      What it works in:

      • JS
      • TS
      • Java
      • C#
      • C++
      • Kotlin
      • Groovy
      • Scala
      • PowerShell

      What produces a number, instead of a string:

      • PHP
      • SQL
      • Perl
      • VB
      • Lua

      What it doesn’t work in:

      • R
      • C
      • Go
      • Swift
      • Rust
      • Python
      • Pascal
      • Ruby
      • Objective C
      • Julia
      • Fortran
      • Ada
      • Dart
      • D
      • Elixir

      And MATLAB appears to produce 51, wtf idk

      • Perhyte@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 months ago

        And MATLAB appears to produce 51, wtf idk

        The numeric value of the ‘1’ character (the ASCII code / Unicode code point representing the digit) is 49. Add 2 to it and you get 51.

        C (and several related languages) will do the same if you evaluate '1' + 2.

    • Semperverus@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      7 months ago

      The JS thing makes perfect sense though,

      “1” is a string. You declared its type by using quotes. myString = "1" in a dynamically typed language is identical to writing string myString = "1" in a statically typed language. You declare it in the symbols used to write it instead of having to manually write out string every single time.

      2 is an integer. You know this because you used neither quotes nor a decimal place surrounding it. This is also explicit.

      "1" + 2, if your interpreter is working correctly, should do the following

      • identify the operands from left to right, including their types.

      • note that the very first operand in the list is a string type as you explicitly declared it as such by putting it in quotes.

      • cast the following operands to string if they are not already.

      • use the string addition method to add operands together (in this case, this means concatenation).

      In the example you provided, "1" + 2 is equivalent to "1" + "2", but you’re making the interpreter do more work.

      QED: "1" + 2 should, in fact, === "12", and your lack of ability to handle a language where you declare types by symbols rather than spending extra effort writing the type out as a full english word is your own shortcoming. Learn to declare and handle types in dynamic languages better, don’t blame your own misgivings on the language.

      Signed, a software engineer.

      • lwuy9v5@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        TypeError is also a correct response, though, and I think many folks would say makes more sense. Is an unnecessary footgun

    • fl42v@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      7 months ago

      Well, C has implicit casts, and it’s not that weird (although results in some interesting bugs in certain circumstances). Python is also funny from time to time, albeit due to different reasons (e.g. -5**2 is apparently -25 because of the order of operations)