From 2b8c1f2614fb30e1cdfd0f76a7ebcbc11c26da08 Mon Sep 17 00:00:00 2001 From: Michael H Date: Sat, 20 Jul 2024 18:50:56 -0400 Subject: [PATCH] minor rewording --- docs/spec/narrowing.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/spec/narrowing.rst b/docs/spec/narrowing.rst index 708d79d8..dc611d6e 100644 --- a/docs/spec/narrowing.rst +++ b/docs/spec/narrowing.rst @@ -274,12 +274,13 @@ Because it is possible to attempt to narrow B, but A does not have appropriate information about B (or any other unknown subclass of A!) it's not possible to safely narrow in either direction. The general rule for generics is that if you do not know -all the places a generic class is generic and do not enough of them to be +all the places a generic class is generic and do not check enough of them to be absolutely certain, you cannot return True, and if you do not have a definitive counter example to the type to be narrowed to you cannot return False. In practice, if soundness is prioritized over an unsafe narrowing, -not knowing what you don't know is solvable by erroring out -or by making the class to be narrowed final to avoid such a situation. +not knowing what you don't know is solvable by either +erroring out when neither return option is safe, or by making the class to be +narrowed final to avoid such a situation. In practice, such correctness is not always neccessary, and may work against your needs. for example, if you trust that users implementing