On Sun, Jun 12, 2022, 16:22 Bluenix <bluenixdev@gmail.com> wrote:

I stumbled upon PEP 671 again today, and for what it's worth I fully agree with everything said here.

For the same reasons as you listed, I am generally opposed to PEP 671. Wrapping functions in one way or another is extremely common and this PEP will make a problem which is currently super small much bigger - the inability to have a function's defaults apply without messing with `*args` and `**kwargs`.

The reason this probably isn't brought up a lot is because of the existence of None. A wrapping function can set its default to None matching the wrapped function's default. If the wrapped function were to use PEP 671 this would cause the wrapping function to need to go to dynamic `*args` and `**kwargs` to match this behaviour.

JavaScript users can use `undefined` for this; if you pass `undefined` to a parameter in JavaScript, the default will be applied. I think that Python should have a similar mechanic (but that's another discussion) which would need to be added before PEP 671. Together that adds up to being years away (because of dependencies minimum Python requirement, etc) and at that point I would rather see the current status quo being upheld and PEP 671 deferred.

Tl;Dr PEP 671 makes things worse without other additions

This has been proposed many times. You can check the mailing list history. Such proposals have been even less popular then PEP 671, since it requires a new keyword, which is generally avoided at nearly all costs, and requires it either be restricted to only being used in defs, or will just end up like None where people are passing it as arguments, which defeats the purpose.

You may not like PEP-671, but it at least provides a feasible solution. Using a new special parameter is never going to fly.