It has been clear that there is and will always be multiple different opinions about ?.. Which is fine.
However, not everybody is contributing equally to these discussions.
I’ve (almost) read the entire PEP 505 story from the mailing list and I can see this clearly. Every so often, someone comes and brings up a point that has already been explained or discussed. It really circles back almost to point zero. Which is understandable, because most people won’t read years of discussions going (almost) in circle. It’s even frustrating just to read.
Note: I am part of the problem as well. When I joined the conversation, I had not yet read the history of the conversation.
I had stated the intention to summarize all these discussions, but it’s taken me already some good time and I’m not even halfway through, so I’m not optimistic about it being done anytime soon, if ever. Even less, now that I’m not expecting to write a lot of Python in the near future.
So I’m curious about how to prevent the discussion going around in circle.
Has there been a precedent in PEPs for operator/syntax addition that was discussed a lot? Was it like this for :=? If so, how did that PEP end up moving forward? Did we learn anything from it?
Who are the people who really need to be convinced? And how much convincing do they need?
Discussions can go on for a long time, it’s mainly up to the author to build consensus and move on to the next step when they’re ready and think the PEP is ready.
To expand on this point, the PEP can be submitted at any time - if the discussion is going in circles, the author can stop that simply by submitting. However, the SC is likely to have (strong) reservations about a PEP that can’t achieve consensus in the community, so the arguments for the PEP would need to be very strong to overcome that.
:= lead to the creation of the steering council as the ultimate decision makers. So may not be the best thing to look at for historic precedent since it wasn’t decided with the current system anyway.
One thing I heard from a Swift Core Dev on a podcast (and I apologize I can’t map this to somewhere in their documentation) is during community discussion they have a sort of “accepted in principle” phase, where an idea can be agreed to be needed without bike shedding all the specific design choices
Which as I understand it would be something like people would agree, or not, that a feature like this was deserving of Python syntax, without having to bike shed specifically what that looked like. Then bike shedding on what exactly it looks like can happen once the consensus is it’s worth new syntax, or a standard library builtin, or a module, or whatever.
In searching for this I see they also have a document of commonly proposed ideas they ask people to read through before proposing something new.
Apologies if I’m not remembering this exactly right. But I would be interested if other language communities have solutions for these sometimes very circular discussions.
It seems to me that the syntax isn’t particularly the issue here. Instead, the debate seems to centre around a few points:
Do we even need this? Specifically, this is the whole “you should sanitise your data early” debate.
Do we need navigation operators, or is the basic null-coalescing operator enough?
Should navigation operators handle missing attributes/keys, or should they only handle null values?
It seems to me there’s little or no consensus on any of these (although (3) is by far the most controversial). I certainly don’t think there’s a clear sense that PEP 505 could be “accepted in principle” in the sense that Swift uses.
I certainly don’t think there’s a clear sense that PEP 505 could be “accepted in principle” in the sense that Swift uses.
I agree with that summarization of that discussion, and as I see it, the benefit of it not “accepted in principle” is it would be clear no one should suggest yet another syntax in the hopes it would sway the consensus.
Unless I missed some later discussion, the ?? and maybe the ??= operators are mostly not that controversial and I haven’t seen anyone argue against them recently. Someone should probably write out a new PEP containing just those two and leave PEP 505 to deal with the more complex and controversial ?. and ?[] operators.
Even if there is something I missed, I still think they should be a separate PEP to focus discussions.
Hi, as the author of the linked thread, I just wanted to advertise that I am set on redrafting a PEP that only proposes ?? and ??=. I agree the thread is spiraling, so I’ve decided to step back from it and focus on actually getting something done.
As you’ve noted, very few contributions are novel or productive at this point. There were a couple interesting arguments about ?., but I still firmly believe it should only ever be implemented as a.b if a is not None else None. I’m uninterested in dying on that hill though (I feel I did my best to state my case).
Expect these to receive pushback on the basis that they don’t add enough value on their own. As part of a “suite” of operators (including at least ?. and ?[), they enable fully coherent and useful expressions, but it’s going to be hard to motivate a syntax change for such a minor benefit. (The fallout from the := proposal is worth noting, and the way it forever changed Python’s development, arguably for little more benefit than ?? would offer.)
Your argument will either have to come down to examples (find the recent “return in finally” PEP), fluency (find the matmul PEP), or correctness (don’t bother with this argument, it’s easy to be correct without ??).
IMO, it would still be better to at least start a discussion on the ?? operators independent of the ?.. If the end result of that discussion is “nah, not worth it without the other operators” then we can resume those discussion - although at this point I am pretty sure that the discussion about all 4 operators at the same time will never be productive enough to come to a conclusion.
I think the ?? operator alone has enough value - but I am not going to argue this here, it’s off-topic for this thread.
Discussions for this kind of proposal will always be messy, but one thing that can help build consensus is to evolve the document as you go. PEPs should reflect the questions, concerns and hopes that the community has. If the community brings something up over and over, ideally we should be able to link to a part of the PEP that gets them up to speed and makes them feel like their position is fairly reflected (even if the PEP on balance disagrees).
Incrementally condensing discussion into a PEP is a way to avoid things from going around in circles. The “Rejected ideas” and “Appendix” sections of PEPs are particularly good for this. This can take a fair amount of work. But in my opinion, the right mindset isn’t “convincing people”, it’s informing people. The match statement proposal ended up needing to explain its ideas over four documents, each targeting different audiences! So be it.
The other mindset that is helpful is to attempt to put yourself in the shoes of a Steering Council member. The SC wants to represent the entire community and usually doesn’t want to do anything regrettable or too controversial. If I was on the SC, I would want to read a PEP that a) I feel confident that it crystallises the community discussion and doesn’t leave anything important unaddressed, b) feels like it makes a strong case for the design, in part by showing sufficient exploration of the rest of the design space, c) minimises the amount of additional context I need to go acquire to make an informed decision. What would help you make a decision if you were on the SC?
Please talk about the original topic in the the original topic. Moved off topic posts from here over to there. Just like the linked topic, it seems this one has pretty much said what it needs to and nothing more was being added, so this is staying closed.