Here’s @steve.dower explaining at EuroPython 2022 why he withdrew PEP 505:
The reason I eventually kind of withdrew that is I had I had a really interesting discussion with Raymond Hettinger at one of our core dev sprints where he basically laid out: the features that go into the language actually change the way people program. And it has far more of a follow-on effect than just how that particular thing gets written. It’s going to affect how the rest of the code is written.
So for example, right now if you’re going to append a value into a list, you may check that you’re not appending
Noneand you’ll say, “if I have a good value i’ll put it in the list”. But if you know that when you go to get values out of the list, you’re going toNonecoalesce everything you’re not going to be worried about that.And so you’ll happily throw, you know garbage values into a list, and then they get carried around passed around and show up all over the place and they may get serialised and pickled and and all sorts of stuff. Because when you come to use it that’s when you know you’re going to handle it.
And basically I had this conversation and I thought about it some more and I’m like, I don’t want to encourage that kind of coding in Python. I think being able to trust the value that you have been given, wherever it came from, is kind of a core part of Python and we don’t defensively double check everything before we use it. Because we have the code laid out in a way that we check it when we first get it and then use it and that gives us nice, straight-line readable code that doesn’t have conditions and checks and exception handling all over the place, apart from a few specific things we know about.
So I didn’t like the idea of: if I get this feature in everyone’s going start putting
Nones in lists everywhere, and instead of[1, 2, 3]we’ll have[1, None, None, None, 2, None, None, None, None, None, 3]. So I didn’t like the implication of what what coding might turn into with that feature there.