9 ms·

Modern python (used in production) should be used in conjunction with static type checking apps. Your argument is no longer relevant for modern python. def d

Modern python (used in production) should be used in conjunction with static type checking apps. Your argument is no longer relevant for modern python. def div(x: Int, y: Int) -> Optional[Int]: return x // y if y != 0 else None The above should be what production level python should look like nowadays. https://www.infoworld.com/article/3575079/4-python-type-checkers-to-keep-your-code-clean.html https://www.infoworld.com/article/3575079/4-python-type-chec... That is not to say the type checking situation for python is perfect, far from it, but the situation is good enough that arguments against python that utilize the dynamic nature of the language are mostly no longer relevant.

globular-toast 5y ago
Division by zero should not return None. Is there an aversion to exceptions in "modern" Python?
- pxc 5y ago
  Why not? If there is no quotient, None seems like a good answer to the question ‘what's the quotient?’
  - deltaonefour 5y ago
    I can see where he's coming from. It's the typical reaction of a beginner programmer. None/Null in many languages isn't type checked even if the language itself has static type checking. It can be passed to other functions mysteriously and remain a hidden error. Javascript and C++ are guilty of this. He's complaining of a safety issue most likely. However note the type signature I specified Optional[Int] encodes the None type into the static type checker. In modern programming this implies Null/None safety at the type level. I'm not up to date with the current state of python type checkers so those type checkers may let some things pass depending on some options you set. See my reply to the other guy for a more detailed expose.
    - globular-toast 5y ago
      > I can see where he's coming from. It's the typical reaction of a beginner programmer. This seems like the typical response of someone who posts bait ready to flex their "advanced programmer" knowledge. There's really no need to call out people's level of experience, ever. Personally I'm past the point where I think I've learnt everything so I just ask questions when I don't know.
      - deltaonefour 5y ago
        I am not calling anyone out. Let me be absolutely clear with you, there is NOTHING and I mean absolutely nothing wrong with asking questions or being a beginner programmer. The problem with your earlier post was that you weren't asking a question. You were stating something as if it were a fact.
        globular-toast 5y ago
        I only stated that division by zero shouldn't return None, which you seem to agree with, no? The difference is how you ensuring that doesn't happen. You really only needed to say "this let's you do a static check to make sure you're not dividing by zero".
        deltaonefour 5y ago
        No. I don't agree, I'm saying the None is better so long as you encode the concept of a None into the type. This is done by converting an Int into Optional[Int].
  - globular-toast 5y ago
    It's not that there's no quotient, it's that you shouldn't even have asked what the quotient is.
    - yxhuvud 5y ago
      The thing about exceptions is that they are runtime. Pushing the issue to the type system forces the user to handle the case.
- deltaonefour 5y ago
  This is definitively wrong. Not to comment on "modern" python, but in general if this code returned an exception on division by zero it is definitively worse. The reason is because an exception is a runtime check. It caught an error that is hidden until runtime. The better way is to encode this logic into a static type checking system so this error isn't even permitted to run. With the type Optional[Int], Any other function that utilizes the output type of this function MUST also be an Optional[Int] and not just an Int, meaning that the function signature must handle the None case and this is caught statically before run time. Insofar as the function type signature... python type checkers should handle this error. However tbh I'm not sure how extensive type checkers for python are and whether or not they can track this type of error for the logic itself. For example while the below will catch a type error if you feed it a bad parameter, the signature itself could be wrong and not caught by a type checker: x1: Int = 2 # results in type error (Good) x2: Optional[Int] = None # results in runtime error. This is bad in terms of safety def addOne(x: Optional[Int]) -> Optional[Int]: return x + 1 As far as I know the above is permitted by python type checkers when truly correct code is below: def addOne(x: Optional[Int]) -> Optional[Int]: return x + 1 if x is not None else None However with python 3.10 pattern matching the level of static type checking can increase to the point where this type of safety is 100% possible: https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/. x1: Int = 2 # results in type error (Good) x2: Optional[Int] = None # No error (also good) def addOne(x: Optional[Int]) -> Optional[Int]: match x: case None: # if this case were deleted should result in static type error (also good) return None case _: return x + 1 Not sure if python type checkers can handle the above code, but exhaustive type checking is 100% viable in the future if the syntax utilizes the pattern matching shown above. Haskell and Rust already have this level of type safety. See: https://rustc-dev-guide.rust-lang.org/pat-exhaustive-checking.html https://rustc-dev-guide.rust-lang.org/pat-exhaustive-checkin... What this means in short is that you are wrong. Whatever your notions of "modern" python should be having division by zero return a runtime error instead of a None or an Error type is definitively worse. We are at a point in our technology that this type of error should be caught automatically BEFORE a program even runs. All type errors should be encoded into types and caught via static type checking and NOT via exceptions.

globular-toast 5y ago

Division by zero should not return None. Is there an aversion to exceptions in "modern" Python?

pxc 5y ago
Why not? If there is no quotient, None seems like a good answer to the question ‘what's the quotient?’
- deltaonefour 5y ago
  I can see where he's coming from. It's the typical reaction of a beginner programmer. None/Null in many languages isn't type checked even if the language itself has static type checking. It can be passed to other functions mysteriously and remain a hidden error. Javascript and C++ are guilty of this. He's complaining of a safety issue most likely. However note the type signature I specified Optional[Int] encodes the None type into the static type checker. In modern programming this implies Null/None safety at the type level. I'm not up to date with the current state of python type checkers so those type checkers may let some things pass depending on some options you set. See my reply to the other guy for a more detailed expose.
  - globular-toast 5y ago
    > I can see where he's coming from. It's the typical reaction of a beginner programmer. This seems like the typical response of someone who posts bait ready to flex their "advanced programmer" knowledge. There's really no need to call out people's level of experience, ever. Personally I'm past the point where I think I've learnt everything so I just ask questions when I don't know.
    - deltaonefour 5y ago
      I am not calling anyone out. Let me be absolutely clear with you, there is NOTHING and I mean absolutely nothing wrong with asking questions or being a beginner programmer. The problem with your earlier post was that you weren't asking a question. You were stating something as if it were a fact.
      - globular-toast 5y ago
        I only stated that division by zero shouldn't return None, which you seem to agree with, no? The difference is how you ensuring that doesn't happen. You really only needed to say "this let's you do a static check to make sure you're not dividing by zero".
        deltaonefour 5y ago
        No. I don't agree, I'm saying the None is better so long as you encode the concept of a None into the type. This is done by converting an Int into Optional[Int].
- globular-toast 5y ago
  It's not that there's no quotient, it's that you shouldn't even have asked what the quotient is.
  - yxhuvud 5y ago
    The thing about exceptions is that they are runtime. Pushing the issue to the type system forces the user to handle the case.
deltaonefour 5y ago
This is definitively wrong. Not to comment on "modern" python, but in general if this code returned an exception on division by zero it is definitively worse. The reason is because an exception is a runtime check. It caught an error that is hidden until runtime. The better way is to encode this logic into a static type checking system so this error isn't even permitted to run. With the type Optional[Int], Any other function that utilizes the output type of this function MUST also be an Optional[Int] and not just an Int, meaning that the function signature must handle the None case and this is caught statically before run time. Insofar as the function type signature... python type checkers should handle this error. However tbh I'm not sure how extensive type checkers for python are and whether or not they can track this type of error for the logic itself. For example while the below will catch a type error if you feed it a bad parameter, the signature itself could be wrong and not caught by a type checker: x1: Int = 2 # results in type error (Good) x2: Optional[Int] = None # results in runtime error. This is bad in terms of safety def addOne(x: Optional[Int]) -> Optional[Int]: return x + 1 As far as I know the above is permitted by python type checkers when truly correct code is below: def addOne(x: Optional[Int]) -> Optional[Int]: return x + 1 if x is not None else None However with python 3.10 pattern matching the level of static type checking can increase to the point where this type of safety is 100% possible: https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/. x1: Int = 2 # results in type error (Good) x2: Optional[Int] = None # No error (also good) def addOne(x: Optional[Int]) -> Optional[Int]: match x: case None: # if this case were deleted should result in static type error (also good) return None case _: return x + 1 Not sure if python type checkers can handle the above code, but exhaustive type checking is 100% viable in the future if the syntax utilizes the pattern matching shown above. Haskell and Rust already have this level of type safety. See: https://rustc-dev-guide.rust-lang.org/pat-exhaustive-checking.html https://rustc-dev-guide.rust-lang.org/pat-exhaustive-checkin... What this means in short is that you are wrong. Whatever your notions of "modern" python should be having division by zero return a runtime error instead of a None or an Error type is definitively worse. We are at a point in our technology that this type of error should be caught automatically BEFORE a program even runs. All type errors should be encoded into types and caught via static type checking and NOT via exceptions.