On Sun, Dec 05, 2021 at 08:15:34AM +1100, Chris Angelico wrote: > There are no objects that will behave differently if used in this way. > EVERY object can be a function default argument. Steve's proposal has > some objects (functions with the LB flag set) actually behave > differently - they *will not behave correctly* if used in this way. > This is a restriction placed on the rest of the language.
Its a restriction in name only. I've already given you two work-arounds for the restriction, and one solution to that (non-)problem. We can change the trigger condition if its really an issue. But if we don't, there are still ways to get the result that you want. How many ways are there to remove the restriction that operator dunders cannot return NotImplemented as a first-class value? Zero. Another precedence is the `__new__` dunder. Classes can return anything they like from the constructor, but if you return an instance of the class, it will automatically trigger calling the `__init__` method, whether you want it to or not. You probably see that as a feature. In my "late-bound protocol", the fact that a function with the "late bound" flag triggers calling the function is likewise a feature, not a bug. Unlike NotImplemented and `__new__`, there are at least two work-arounds for the rare case where you don't want that. And as I said, if this is really a show-stopper, we can change the trigger condition. There are pros and cons and I'm not wedded to one way or the other. > You assert that it "belongs in the body", but only because Python > currently doesn't allow it to be anywhere else. Other languages have > this exact information in the function signature. This argument about where the evaluation of the default expression is surreal. Brendan argues in favour of the status quo, because he thinks that the evaluation of the default expression "belongs in the body". You (Chris) argue in favour of your PEP, where the bytecode of the default expression is inlined into the function's body, because you insist that it belongs in the body. You justify that claim by making spurious arguments that it is "impossible" to do otherwise (your term, not mine). But it isn't impossible, and I shall justify that claim in another post. A bold claim for somebody who knows nothing about the C implementation :-) The bottom line is, you both are arguing at each other because you both want the default expression to be executed in the body of the function o_O > You're still being highly offensive here. Everyone please chill a bit. Taking offence at vigourous but still respectful intellectual disagreement is not kind or welcoming and most of all it is not *helpful*. Brendan has not accused you of molesting children or betraying a position of trust. He hasn't even suggested you have bad breath. He has merely disagreed with your interpretation of a proposed programming language feature. Is it really worth taking offence over that? And if you think Brendan is not being *respectful* because his opinion is so obviously *wrong* (in your view), well, fine. Suppose you are right. Does it matter? Should you challenge him to pistols at dawn for besmirching your honour? Chris, I know this has been a long, hard PEP for you. Here is a feature that people in the Python community say they want, you write a PEP proposing it, and you get nothing but negativity. Ouch :-( Well, not nothing but negativity. There has been some support. And I didn't spend six hours researching and writing up evaluation strategies of nearly two dozen languages because I'm trying to sabotage your proposal. You and I may disagree with some details of this PEP, but I'm supporting it and want it to be the best late-bound feature it can be. -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/L2CBFIQFTVKEJYHWEH7JV3VB7I76367Q/ Code of Conduct: http://python.org/psf/codeofconduct/
