On Mon, Dec 06, 2021 at 02:08:46AM +1100, Chris Angelico wrote:

> I want to have them syntactically as part of the body
> of the function, and semantically as part of the function call.

Then you'll love the status quo, because that's exactly what we have 
now! *wink*


> As a function begins executing, a ton of stuff happens, including 
> allocating arguments to parameters, and providing default values for 
> optional parameters that weren't passed.

And neither of those things are part of the function body. They are 
set up *before* the function's code object is called.


> All I want to change is the way that defaults can be provided.

Right. And the community reaction on this mailing list is underwhelming. 
Apart from Abe, who is rather vigourly in favour of the PEP as it 
stands, I'm not really sure this PEP has much support as it stands now.

And one of the most frequent issues raised is that **all** you want to 
do is change the way that the late defaults can be provided.

You're the PEP author, but maybe you should consider listening to 
community feedback? Just sayin'.


> Tell me, what's the first bytecode instruction in the function g here?
>
> def f(x):
>     print(x)
>     return lambda: x

Why do you think that is an argument against my position? As you said:

> CPython bytecode is an implementation detail, and the fact that
> there's bytecode to do this or that is not part of the language
> definition.

Bytecode can and does change.

I'm talking about the language definition: late bound defaults should be 
compiled into their own publicly accessible callable functions. I don't 
care what bytecode is emitted to do that. Whatever it is, it will change 
in the future, without changing the Python semantics one whit.


> And if you want an _implementation function for external testing,
> you're still welcome to do that.

Oh, thank goodness! I thought your PEP was going to ban the use of 
function calls as the default expression!!! *wink*


> def func(arg=>_implementation()):
>     ...
> 
> No magic, just perfectly normal coding practices.

You've just made a good argument against your own PEP. We don't need new 
syntax for late-bound defaults, just use the perfectly normal coding 
practices that have worked fine for 30 years.


> If something's
> important enough to test separately, refactor it into a private
> function so you can call it. Why should this happen automatically for
> late-bound argument defaults? 

Sure. And why should early-bound defaults be available in a publicly 
accessible dunder attribute, when they could be compiled directly into 
the function code object?

Hell, the entire code object, and most of the function object, could 
be compiled into one great big opaque ball of mud. Aside from standard 
attributes inherited from object, all the function really needs is a 
name and a binary blob of everything else.

But that's not the sort of language we have.


-- 
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/XIKO3B52GMGKGPNER7Y6QYWRPRQIA5QW/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to