On 2021-12-08 15:17, Chris Angelico wrote:
At a minimum, the PEP should state the objections fairly, and note that the PEP author disagrees. A PEP isn't a sales pitch, it's a summary of the discussions - so it absolutely should mention that there's been significant opposition to the proposal, which did not get resolved, if that's the reality. Yes, and "significant opposition" doesn't just mean "I don't like this". There's nothing to respond to in that.
Well, in a way it does. In another message on this thread you wrote:
I have attempted to explain the syntax. What is confusing?
def f(x=spam): ...
def f(x=>spam): ...
I'm not sure what concerns need to be addressed, because I don't understand the concerns.
Speaking for myself, I would agree that there is nothing for you to "address" per se. The problem, though, is that if half the people in the discussion think it is confusing, then that in itself constitutes a case that it is confusing and maybe we shouldn't add it. It's possible this is why this discussion is kind of going in circles, because a lot of it does come down to a somewhat subjective judgment about what is "too confusing". But that doesn't mean that the subjective disagreement about the relative costs and benefits doesn't exist, or that there is some external source of truth about whether it "really is" confusing. Your example there is very simple. But for me a lot of it comes down to this: def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)): The PEP envisions a world in which you can have a list of arguments like that, alternating back and forth between early and late binding, and they can refer to each other in arbitrary ways, and the semantics will differ from one argument to another (in that, e.g., for c the arguments a and b will be evaluated in the enclosing scope, whereas for d they are evaluated in the function scope). And yet none of the late-bound defaults will exist as objects or be accessible or creatable in any way apart from in function signatures, so all of this complexity, insofar as it exists, is necessarily going to be crammed entirely into function signatures, and also provide no benefit anywhere else. Now certainly it is possible to write confusing code now, and on some level any language that allows arbitrary nesting of expressions allows arbitrarily confusing code. But from my perspective, the point is that introducing this entire new "way" for things to be confusing just isn't worth it for the benefit this PEP provides. Of course we can say "well people could write confusing code like that but they won't/shouldn't/etc.". But to my mind there is no reason to even give them the chance. There would need to be a lot more than just "I don't have to do an if-None check" to justify this new "surface area" of complexity. I agree with you that it is unclear how you would "address" this objection, but that doesn't mean it's not a valid objection. To me it is sort of an "irreducible" objection, in the sense that I don't currently see how it could possibly be addressed and therefore I am against the PEP outright. Maybe someone could come up with some alternative mechanism for late-bound defaults that I would think was fine, but as of now it's hard for me to envision what that could possibly be. From where I stand it is like someone told me they were going to put a horse into a suitcase; unless it turns out the suitcase has a false bottom, or someone comes up with a kind of horse or suitcase I've never seen before, it just fundamentally will not fit. To touch on the "deferred" issue, I will also say it's quite possible that someone might come up with a proposal for deferred evaluation and I would still oppose it because I thought it was too confusing. That's really neither here nor there. It's not that I oppose this PEP because I think we can get some great deferred-eval PEP instead; it's just that the benefit this PEP provides is too small to justify the complexity. Now, I can add to that that in theory (in theory!) one reason I might look differently on a deferred-eval proposal is that such a proposal could provide benefits OUTSIDE of function signatures. Because your proposal focuses only on function signatures, it can provide no benefit outside of function signatures, and (in my view) there simply isn't enough potential benefit available within function signatures to outweigh the possibility of confusion that I outlined above. The cost-benefit account of function signatures is overdrawn. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown