I'm going to decline this one.  It seems that you're applying a stylistic guideline to a case where it isn't needed and where it doesn't improve the example.

In this case, the example doesn't mutate the input, so the code is correct.  It has some benefit in that it communicates to the user of the function that lists are allowable as an input (which is the norm for bisect).  And the tooltips will show the relationship between the grades can the cutpoints.

Also, this isn't library code.  A bisect example needs to focus on bisect rather than other concerns.  This isn't the place to talk about the pattern of setting a default to None and then filling it in in the body of the code.  Likewise, we wouldn't use this example to communicate / and * for positional-only and keyword-only args.  Nor do we have a docstring or type signature.  Instead, it shows how to write a lookup function using bisect() and that is all we want.

Lastly, I'll note this example has been present for a long time and has proven itself effective in teaching people how bisect works.  In particular, we want to make it obvious the relationship between the 5 grades and the 4 cut points.