2020-03-29

4: To Use or Not to Use mypy Strict Optional-Checking Feature

<The previous article in this series | The table of contents of this series | The next article in this series>
In fact, the feature is rather dull-witted. Here cited are some cases, which may render the feature too annoying to be worth using.

Topics


About: The Python programming language
About: mypy

The table of contents of this article

Starting Context

Target Context


  • The reader will know some cases of dull-wittedness of the mypy strict optional-checking feature and some solutions for them.

Orientation


There is an article on why mypy or a like should be used in the 1st place.

Main Body

1: The Intention is Good, but . . .


Hypothesizer 7
 I have left the mypy strict optional-checking feature turned on (as is turned on by default) because it seems helpful as a concept. . . . In fact, it will be good if null pointer exceptions (Python variables are pointers, as I persist to declare) are statically prevented.

However, the realization of the intention is too dull-witted not to be a nuisance sometimes, and I have recently encountered a case of a new type of dull-wittedness, which I will see in the next section.

There is an end run certainly, but I began to wonder whether the feature was worth putting in such dirty end runs.

2: A Problem About List Optional Variable-Indexed Elements


Hypothesizer 7
 This piece of code is flagged as a problem by mypy.

@Python Source Code 
		l_listOfOptionals: List [Optional [str]] = ["AAA", "BBB"]
		l_index: int = 0
		if l_listOfOptionals [l_index] is not None:
			print ("### " + l_listOfOptionals [l_index])

The error message and its note are these: "error: Unsupported operand types for + ("str" and "None")" and "note: Right operand is of type "Optional[str]"".

Hmm, I thought that that non-'None' checking should prevent the error . . .

Using 'assert' like this also does not work.

@Python Source Code 
		assert l_listOfOptionals [l_index] is not None
		print ("### " + l_listOfOptionals [l_index])

Is my code a problem? I would say that mypy was the problem.

For any simple optional variable, this is good.

@Python Source Code 
		l_optionalString: Optional [str] = "AAA"
		if l_optionalString is not None:
			print ("### " + l_optionalString)

The problem seems to be about List optional elements . . .

However, this is good.

@Python Source Code 
		if l_listOfOptionals [0] is not None:
			print ("### " + l_listOfOptionals [0])

It seems that checking any literal-indexed element works.

So, more precisely speaking, the problem seems to be about List optional variable-indexed elements. I guess that mypy cannot recognize that the indexing variable does not change between the non-'None' checking and the flagged line, even thought there is no line between them . . .

So, what should I do? . . . Obviously, there is an end run like this.

@Python Source Code 
		l_listElement: Optional [str]
		l_listElement = l_listOfOptionals [l_index]
		if l_listElement is not None:
			print ("### " + l_listElement)

That works certainly, but should I really be forced to do such a thing?

Another solution is to rather turn off the strict optional-checking feature.

The feature can be turned off by adding the '--no-strict-optional' switch into the mypy command.

3: A Plainer Case of Dull-Wittedness


Hypothesizer 7
 Without any necessity of citing such a special case (if that is really special), mypy cannot recognize that this variable is not at 'None' in this code.

@Python Source Code 
		l_optionalString: Optional [str] = "AAA"
		print ("### " + l_optionalString)

. . . So, I have to do like this.

@Python Source Code 
		l_optionalString: Optional [str] = "AAA"
		if l_optionalString is not None:)
			print ("### " + l_optionalString))

Is that not ridiculous? Do I have to check that the variable is not at 'None' just after 'AAA' is plainly put into it?

4: To Use or Not to Use the Feature


Hypothesizer 7
 It is not just my imagination that the feature is dull-witted, right?

. . . Well, I am going to turn the feature off, at least until the feature becomes less dull-witted.

References
<The previous article in this series | The table of contents of this series | The next article in this series>
Posted by at
Labels: