Yeah very good points! As long as you designed the functions to be used for the
pipeline, then we’re fine. However, you might force the programmer to write
unnecessary functions (almost boil-plate code of switching arguments around)
based on already existing optimized functions scattered
On Fri, Dec 3, 2021 at 3:47 PM Abe Dillon wrote:
> This seems like an exceedingly minor complaint. The obvious answer is: you
> invoke the default behaviour by not passing the argument. And yes, I know
> that's less explicit, but that's kinda the whole point of defaults to begin
> with. It's
On Fri, Dec 3, 2021 at 2:30 PM Brendan Barnwell wrote:
>
> On 2021-12-02 15:40, Chris Angelico wrote:
> > Actually, no. I want to put the default arguments into the signature,
> > and the body in the body. The distinction currently has a technical
> > restriction that means that, in certain
"You've gone from talking about *my* intentions, which you got wrong, to
an argument about which is "more explicit"."
No. You were the one who brought up explicitness by claiming that using a
sentinel value was a way to "explicitly tell the function "give me the
default value" (whatever the heck
On Fri, Dec 3, 2021 at 2:24 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 01:08:50PM +1100, Chris Angelico wrote:
>
> > How, with external calling, are you going to know which name
> > references to look up, and where to get their values from?
>
> Isn't the source code available as a
On Fri, Dec 3, 2021 at 2:27 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 10:36:55AM +1100, Chris Angelico wrote:
>
> > Same again. If you consider the equivalent to be a line of code in the
> > function body, then the signature has become MASSIVELY more useful.
> > Instead of simply
Ah, I think I get you. The problem is that code is in the def line but
is only executed when the function is called, is that correct? Because
the code would be "re-executed" just as much if it were written in the
function body. It's executed (at most) once for each call to the
function, just like
On 2021-12-02 15:40, Chris Angelico wrote:
Actually, no. I want to put the default arguments into the signature,
and the body in the body. The distinction currently has a technical
restriction that means that, in certain circumstances, what belongs in
the signature has to be hacked into the
On Fri, Dec 03, 2021 at 10:36:55AM +1100, Chris Angelico wrote:
> Same again. If you consider the equivalent to be a line of code in the
> function body, then the signature has become MASSIVELY more useful.
> Instead of simply seeing "x=", you
> can see "x=>[]" and be able to see what the value
On Fri, Dec 03, 2021 at 01:08:50PM +1100, Chris Angelico wrote:
> How, with external calling, are you going to know which name
> references to look up, and where to get their values from?
Isn't the source code available as a string? I will see the names in the
expression.
Or I will disassemble
On Thu, Dec 02, 2021 at 01:20:27PM -0800, abed...@gmail.com wrote:
> If you want the parameter to default to an empty list, it's categorically
> more explicit to have the parameter default to an empty list.
You've gone from talking about *my* intentions, which you got wrong, to
an argument
On Fri, Dec 3, 2021 at 12:48 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 02:10:12AM +1100, Chris Angelico wrote:
>
> > > > Unfortunately not, since the default expression could refer to other
> > > > parameters, or closure variables, or anything else from the context of
> > > > the
On Fri, Dec 03, 2021 at 02:10:12AM +1100, Chris Angelico wrote:
> > > Unfortunately not, since the default expression could refer to other
> > > parameters, or closure variables, or anything else from the context of
> > > the called function. So you won't be able to externally evaluate it.
> >
>
There was a typo in my post and I want to avoid getting into a pedantic
tangent about how to properly indent multi-line function signatures, so
hopefully this will "nip it in the bud", so to speak.
When I wrote:
def my_func(
param: Annotation[stuff],
other_param:
On Fri, Dec 3, 2021 at 9:26 AM Brendan Barnwell wrote:
>
> On 2021-12-02 00:31, Chris Angelico wrote:
> > Here's how a ternary if looks:
> >
> >>>def f(n):
> > ... return 0 if n == 0 else 42/n
> > ...
> >>>dis.dis(f)
> >2 0 LOAD_FAST0 (n)
> >
On Fri, Dec 3, 2021 at 8:07 AM David Mertz, Ph.D. wrote:
>
> On Thu, Dec 2, 2021 at 2:40 PM Chris Angelico wrote:
>>
>> How is a late-bound default different from half of a conditional expression?
>
>
>>
>> def f(lst=>[], n=>len(lst)):
>>
>>
>> def f(*args):
>> lst = args[0] if len(args) >
On Fri, Dec 3, 2021 at 7:54 AM Eric V. Smith wrote:
>
> On 12/2/2021 2:21 PM, Brendan Barnwell wrote:
> > On 2021-12-02 01:35, Steven D'Aprano wrote:
> > >4) If "no" to question 1, is there some other spelling or other
> small
> > >change that WOULD mean you would use it? (Some
On Fri, Dec 3, 2021 at 6:50 AM Oscar Benjamin
wrote:
>
> On Thu, 2 Dec 2021 at 17:28, Chris Angelico wrote:
> >
> > On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole
> > wrote:
> > > There is nothing that this proposal makes possible that is not already
> > > possible with more explicit code.
> >
>
"The caller cannot explicitly ask for default behaviour except by omitting
the parameter. This can be very annoying to set up when the parameter
values are provided from other places, e.g.,
if need_x:
# do lots of stuff
x = whatever
else:
# do more
x = None
f(x=x, ...) # easy, but with
On 2021-12-02 00:31, Chris Angelico wrote:
Here's how a ternary if looks:
>>>def f(n):
... return 0 if n == 0 else 42/n
...
>>>dis.dis(f)
2 0 LOAD_FAST0 (n)
2 LOAD_CONST 1 (0)
4 COMPARE_OP 2 (==)
Steven D'Aprano
"> My favorite alternative is ?= if people think => and -> are getting
> overly loaded. What I really don't like is @param=[] because it puts the
> emphasis on the parameter name rather than the act of binding. Not only
> does it make it look like @param is a special kind of
Steven D'Aprano
"> ""If param is missing **or None**, the default if blah..."
> The bottom line is:
>
> you *don't actually* want the parameter to default to the value of a
> sentinel.
Yes I do. I *do* want to be able to give a convenient sentinel value in
order to explicitly tell the function
On Thu, Dec 2, 2021 at 2:40 PM Chris Angelico wrote:
> How is a late-bound default different from half of a conditional
> expression?
>
> def f(lst=>[], n=>len(lst)):
> def f(*args):
> lst = args[0] if len(args) > 0 else []
> n = args[1] if len(args) > 1 else len(lst)
>
Although
On 12/2/2021 2:21 PM, Brendan Barnwell wrote:
On 2021-12-02 01:35, Steven D'Aprano wrote:
> >4) If "no" to question 1, is there some other spelling or other
small
> >change that WOULD mean you would use it? (Some examples in the
PEP.)
>
> No. As I mentioned in the earlier thread, I don't
Nicholas Cole
"There is nothing that this proposal makes possible that is not already
possible with more explicit code."
There's nothing any of Python's syntax makes possible that is not already
possible with Brainfuck or any other language that's Turing complete. The
current hacks used to get
On Thu, 2 Dec 2021 at 17:28, Chris Angelico wrote:
>
> On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole wrote:
> > There is nothing that this proposal makes possible that is not already
> > possible with more explicit code.
>
> It's worth noting that "explicit" does not mean "verbose". For
>
On Fri, Dec 3, 2021 at 6:24 AM Brendan Barnwell wrote:
> What I'm saying is that I want that "thing" to exist. At the time the
> function is defined, I want there to be a Python object which represents
> the behavior to be activated at call time if the argument is not passed.
> In the
On 2021-12-02 01:35, Steven D'Aprano wrote:
> >4) If "no" to question 1, is there some other spelling or other small
> >change that WOULD mean you would use it? (Some examples in the PEP.)
>
>No. As I mentioned in the earlier thread, I don't support any
>proposal in which an argument
On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole wrote:
> There is nothing that this proposal makes possible that is not already
> possible with more explicit code.
It's worth noting that "explicit" does not mean "verbose". For
instance, this is completely explicit about what it does:
x += 1
It
On Wed, Dec 1, 2021 at 6:18 AM Chris Angelico wrote:
>
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound function argument defaults*
On Wed, Dec 01, 2021 at 09:00:50PM -0800, abed...@gmail.com wrote:
> Steven D'Aprano
> ""If param is missing **or None**, the default if blah..."
> The bottom line is:
>
> you *don't actually* want the parameter to default to the value of a
> sentinel.
Yes I do. I *do* want to be able to give
On Fri, Dec 3, 2021 at 2:17 AM Steven D'Aprano wrote:
>
> On Wed, Dec 01, 2021 at 09:58:11PM -0600, Abe Dillon wrote:
>
> > My favorite alternative is ?= if people think => and -> are getting
> > overly loaded. What I really don't like is @param=[] because it puts the
> > emphasis on the
On Wed, Dec 01, 2021 at 09:58:11PM -0600, Abe Dillon wrote:
> My favorite alternative is ?= if people think => and -> are getting
> overly loaded. What I really don't like is @param=[] because it puts the
> emphasis on the parameter name rather than the act of binding. Not only
> does it make
On Fri, Dec 3, 2021 at 2:11 AM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 02/12/2021 14:47, Steven D'Aprano wrote:
> > On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote:
> > I'm still unsure whether this is a cool feature or an utter abomination:
> > def f(x=...):
> >> ...
On Fri, Dec 3, 2021 at 1:53 AM Steven D'Aprano wrote:
>
> On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote:
> > On Thu, Dec 2, 2021 at 8:40 PM Steven D'Aprano wrote:
> > > Depending on the implementation, you *might* be able to inspect the
> > > function and see the default
On 02/12/2021 14:47, Steven D'Aprano wrote:
On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote:
I'm still unsure whether this is a cool feature or an utter abomination:
def f(x=...):
... try: print("You passed x as", x)
... except UnboundLocalError: print("You didn't pass
On Fri, Dec 3, 2021 at 12:43 AM David Mertz, Ph.D.
wrote:
>
> On Thu, Dec 2, 2021 at 3:33 AM Chris Angelico wrote:
>>
>> > But it IS stored! There is no way for it to be evaluated without
>> > it
>> > being stored!
>> >
>> I'm not sure I understand you here. How is the late-bound
On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote:
> On Thu, Dec 2, 2021 at 8:40 PM Steven D'Aprano wrote:
> > Depending on the implementation, you *might* be able to inspect the
> > function and see the default expression as some sort of callable
> > function, or evaluatable code
On Thu, Dec 2, 2021 at 3:33 AM Chris Angelico wrote:
> > But it IS stored! There is no way for it to be evaluated
> without it
> > being stored!
> >
> I'm not sure I understand you here. How is the late-bound default
> "stored" when one side of a ternary is "not stored"?
>
This seems
On 01/12/2021 06:16, Chris Angelico wrote:
I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
with some additional information about the reference implementation,
and some clarifications elsewhere.
*PEP 671: Syntax for late-bound function argument defaults*
Questions, for
On 01/12/2021 15:39, David Mertz, Ph.D. wrote:
However, even if I assume the mythical future PEP never happens, in
terms of readability, a WORD is vastly less confusing than a
combination of punctuation that has no obvious or natural
interpretation like '=>'. Or rather, I think that
On 02/12/2021 07:05, Brendan Barnwell wrote:
On 2021-12-01 18:35, Chris Angelico wrote:
In my reference implementation, there is no object that stores it;
it's simply part of the function. A good parallel is the if/else
expression:
x = float("inf") if z == 0 else y/z
Is there an object that
On 02/12/2021 03:35, Steven D'Aprano wrote:
On Wed, Dec 01, 2021 at 05:16:34PM +1100, Chris Angelico wrote:
1) If this feature existed in Python 3.11 exactly as described, would
you use it?
Yes I would, but probably not as often as counting cases of the "if
param is None: ..." idiom might
On 01/12/2021 10:05, Steven D'Aprano wrote:
Oh great, now you're going to conflict with walrus...
def process(obj:Union[T:=something, List[T]]:=func(x:=expression)+x)->T:
We ought to at least try to avoid clear and obvious conflicts between
new and existing syntax.
Using `:=` is even
On Thu, Dec 2, 2021 at 8:40 PM Steven D'Aprano wrote:
> Depending on the implementation, you *might* be able to inspect the
> function and see the default expression as some sort of callable
> function, or evaluatable code object. (That would be nice.)
Unfortunately not, since the default
On Thu, Dec 02, 2021 at 08:29:58AM +, Paul Moore wrote:
> 1. It's hard (if not impossible) to wrap functions that use late-bound
> defaults.
I don't understand that argument.
We can implement late-bound defaults right now, using the usual sentinel
jiggery-pokery.
def func(spam, eggs,
On Wed, Dec 01, 2021 at 10:50:38PM -0800, Brendan Barnwell wrote:
> >4) If "no" to question 1, is there some other spelling or other small
> >change that WOULD mean you would use it? (Some examples in the PEP.)
>
> No. As I mentioned in the earlier thread, I don't support any
>
On Thu, Dec 2, 2021 at 7:36 PM Paul Moore wrote:
>
> Actually, Chris - does functools.wraps work properly in your
> implementation when wrapping functions with late-bound defaults?
>
> >>> def dec(f):
> ... @wraps(f)
> ... def inner(*args, **kw):
> ... print("Calling")
> ...
Abdulla Al Kathiri writes:
> Thanks for the clarification. Yeah I agree it will look ugly if we
> use it not as a first argument many times in a row but what if
> there is one or two functions in the middle that they are not
> playing along and don’t have teamwork ethics,
Function
On Thu, Dec 2, 2021 at 7:31 PM Paul Moore wrote:
>
> On Wed, 1 Dec 2021 at 22:27, Greg Ewing wrote:
> >
> > On 2/12/21 4:40 am, Paul Moore wrote:
> > > the
> > > intended use is that people must supply a list[int] or not supply the
> > > argument *at all*.
> >
> > I don't think this is a style
On Thu, 2 Dec 2021 at 08:29, Paul Moore wrote:
>
> On Wed, 1 Dec 2021 at 22:27, Greg Ewing wrote:
> >
> > On 2/12/21 4:40 am, Paul Moore wrote:
> > > the
> > > intended use is that people must supply a list[int] or not supply the
> > > argument *at all*.
> >
> > I don't think this is a style of
On Thu, Dec 2, 2021 at 6:59 PM Brendan Barnwell wrote:
>
> On 2021-12-01 23:36, Chris Angelico wrote:
> > That's exactly why it's such a close parallel. The late-evaluated
> > default is just code, nothing else. It's not "stored" in any way - it
> > is evaluated as part of the function beginning
On Wed, 1 Dec 2021 at 22:27, Greg Ewing wrote:
>
> On 2/12/21 4:40 am, Paul Moore wrote:
> > the
> > intended use is that people must supply a list[int] or not supply the
> > argument *at all*.
>
> I don't think this is a style of API that we should be encouraging
> people to create, because it
53 matches
Mail list logo
