On Mon, Dec 6, 2021 at 10:02 PM Steven D'Aprano <st...@pearwood.info> wrote: > > 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 :-)
I am arguing that it belongs in the *header*. I think I once mistyped that and said "body" by mistake, but I have never intentionally advocated for that (and you called me out on it promptly for a correction). Default expressions, whether evaluated at definition time or call time, belong in the header. With definition-time expressions, their code is inlined into the body of the surrounding context. With call-time expressions, their code is inlined into the body of the function. Neither of these is part of the signature, but that's because the signature doesn't itself have any code. > 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 conflating implementation with syntax. I want it to be implemented in the body, because that's clean and efficient *for implementation*. I want it to be written in the signature, because that's where function defaults belong. You're asking for it to be written in the signature, same as I am, but then to have it executed... somewhere else. But still in basically the same place. > > 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? He apologized privately and we have settled that matter. Let's drop it. > 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. Thank you, I do appreciate that. Still, it does get somewhat tiresome when there is a dogpile of negativity about the proposal, much of it unbacked by any sort of code, and just declaring that what I've said doesn't work or isn't ideal or should be left off because of a hypothetical future feature. Very tiresome. ChrisA _______________________________________________ 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/GVGNYWQUZ5UDSC6PXCC7JCFHQWYEQLVE/ Code of Conduct: http://python.org/psf/codeofconduct/
