[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    [Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
From:       Todd <toddrjen () gmail ! com>
Date:       2022-06-13 11:41:12
Message-ID: CAFpSVpL4fFyssmkA6mjmqH=ZQ4Ug7vFBuXSigayM-OFAhOjqzg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.

[Attachment #5 (text/html)]

<div dir="auto"><div dir="auto">On Sun, Jun 12, 2022, 16:22 Bluenix &lt;<a \
href="mailto:bluenixdev@gmail.com">bluenixdev@gmail.com</a>&gt; wrote:<br></div><div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I stumbled upon PEP 671 again today, and for what it&#39;s worth I fully agree \
with everything said here.<br> <br>
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&#39;s defaults apply without messing with `*args` and `**kwargs`.<br> \
<br> The reason this probably isn&#39;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&#39;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.<br> <br>
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&#39;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.<br> <br>
Tl;Dr PEP 671 makes things worse without other additions</blockquote><div dir="auto"><br><br></div><div \
dir="auto"><div class="elided-text"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">You may not like PEP-671, but it at least \
provides a feasible solution. Using a new special parameter is never going to fly.  \
</div></div></div></div></div></div>



_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/YFONN2M73HZE6CGQL2SYSGBOEK2AJCKQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[prev in list] [next in list] [prev in thread] [next in thread]