Thanks to everyone for many thoughtful comments. I'm going to try to wrap this up.
So I talked above about how the IDEs have this very visual way of nudging beginning students to write their code to conform to PEP8, and this is the IDE default. Mostly this is a great, constructive dynamic, nudging students to follow the community standard.
As someone who spends all their time in the land of Python-beginners, I hope this little report of how the IDEs nudge the beginners can be taken as a success story by people who care about PEP8.
I should say, I'm not worried about Stanford students, they're going to be fine. In reality, I'm playing a long game here. I'm pushing for Python to grow to be the dominant intro teaching language (currently it's Java). I do not want the tooling by default to be flagging correct uses of == for, say, a highschool student a few years from now who is firing up the IDE to get started coding. Anyway, this is why I'm trying to get a little shift in the IDE default now.
I want to get a phrasing into PEP8 so I can go to PyCharm et al, and get a little shift in their default behavior. PEP8 coloring in the IDE should remain on by default. That has many fantastic qualities as it works with the beginning students. But in the default configuration, I want the PEP8 scoring to be tolerant about "== None" for non-Python-implementation code.
My original proposal was to add this parenthetical to the mandatory-is rule: "(this rule is optional for code that is not part of a Python implementation)".
Or maybe just a weak nudge to the tooling, like "(it's permissible for tooling to leave E711 off by default, though it is required for Python implementation code)". (ht Steven D'Aprano pointing out the proper numbers
https://pep8.readthedocs.io/en/release-1.7.x/intro.html#error-codes)
Then I can go to PyCharm et al and say - hey, for new empty projects could you please default to PEP8 checking on but E711 off.
Is there support for such a change? The replies on this thread I would say are mostly not supportive...
Just using Todd recent reply as an example - describing == as "brittle". Then some point out that understanding equality and identity is important, so in effect this justifies getting "is" in front of the students even where == works. Then there's a practical view that being tolerant of "== None" may be a thing, but messing with PEP8 is not the way.
Is there anyone other than me who would like to push for "== None tolerant" carve out for non-Python-implementation code?
Best,
Nick