On Tue, Aug 31, 2021 at 2:18 PM Nick Parlante <nick@cs.stanford.edu> wrote:
Hi Steven, I wish I could blame this on zealots, so let me talk a little bit about how PEP8 works in education, and I'll talk about moving forward in another message.
As mentioned, PEP8 is formally for narrow cases, and includes disclaimers about not applying it mechanically, reflecting a basic reasonableness. Nothing to complain about there.
As a practical matter, the IDEs just default to having PEP8 checking on, and they do it in a very visual way - akin to a text editor which puts little squiggles under words it thinks are misspelled.
This maybe sounds annoying, but looking at how people learn to code, it's actually fantastic, and a giant success for the goals of PEP8. Instead of spending lecture time at some point reviewing rules about spacing or whatever, the students are absorbing that stuff just imperceptibly as the IDE is nudging them the right way by putting little colored marks around code it doesn't like. PEP8 contains a bunch of conventions, and now you have this crop of junior programmers who have absorbed the important ones, thus avoiding future pointless bikeshed wars.
I hope people who care about PEP8 can have a moment of satisfaction, appreciating how IDEs have become a sort of gamified instrument to bring PEP8 to the world at low cost. So that's the good news.
The visual quality that makes the IDEs so effective, also loses all the nuance. I have tried to explain to the students this or that they can let slide, but as a matter of human nature, it's hopeless. They want to get rid of the IDE marked code. And keep in mind, their devotion to that is mostly a force for good.
So this basically great, but rather inflexible dynamic of the students, the IDEs, and PEP8 is what brings me here.
I want to get to a world that is, let's say, "== tolerant". I claim you can teach a nice intro course using == early in the course, and many people have chimed in that they feel there's value in "is". I want to work out a solution between PEP8 and the IDEs where both approaches are permitted.
Let me write up some proposals in a separate message, and people can comment on those.
Best,
Nick
Before we can start talking about solutions, we need to first establish there is an actual problem to be solved to begin with. Nobody who has commented here agrees with you on that. So you need to convince people this is actually something that needs to be fixed in the first place before anyone will consider any fixes. Using "==" is a brittle approach that will only work if you are lucky and only get certain sort of data types. "is" works no matter what. The whole point of Python in general and pep8 in particular is to encourage good behavior and discourage bad behavior, so you have an uphill battle convincing people to remove a rule that does exactly that. People learning Python MUST know the difference between equality and identity. It is one of the most central aspects of the language, and they WILL write horribly broken code if they don't, even at a beginner level. So we are talking about an issue that will only ever slightly and briefly surprise the very most beginning students, assuming they have an IDE that marks pep8 violations and assuming their lecturers don't just tell them to turn that feature off until it is needed or give them a config file to change it. That is not sufficient justification to throw away a good rule that exists for a good reason. So my proposal is for you to treat it as a learning opportunity for your students rather than an obstacle. They need to learn about the distinction between equality and identity, ideally sooner rather than later, and this is a great jumping-off point for that.