[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 4:55 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-10-31 at 14:56:36 +1100, > Chris Angelico wrote: > > > On Sun, Oct 31, 2021 at 2:43 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > > > > > On 2021-10-30 at 18:54:51 -0700, > > > Brendan Barnwell wrote: > >

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 10:51:42PM -0700, 2qdxy4rzwzuui...@potatochowder.com wrote: > I still see anything more complicated than a constant or an extremely > simple expression (len(a)? well, ok, maybe; (len(a) if is_prime((len(a)) > else next_larger_prime(len(a)))? don't push it) as no longer bei

[Python-ideas] Lisp vs PEP 671

I'm not sure this answers Chris's question about "technical and emotional baggage," but I hope to clarify the Lisp model a bit. 2qdxy4rzwzuui...@potatochowder.com writes: > As prior art, consider Common Lisp's lambda expressions[...]. > The human description language/wording is different; , but

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 4:37 PM Steven D'Aprano wrote: > > On Sun, Oct 31, 2021 at 02:56:36PM +1100, Chris Angelico wrote: > > > Current versions of the PEP do not use the term "default value" when > > referring to late binding (or at least, if I've made a mistake there, > > then please point it o

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 09:31:38PM -0400, David Mertz, Ph.D. wrote: > Both the choice of syntax and the discussion of proposed implementation > (both yours and Steven's) would make it more difficult later to advocate > and implement a more general "deferred" mechanism in the future. The choice of

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 4:15 PM Steven D'Aprano wrote: > > On Sun, Oct 31, 2021 at 03:43:25PM +1100, Chris Angelico wrote: > > > There is a downside: it is possible to flat-out lie to the > > interpreter, by mutating bisect_left.__defaults__, so that help() will > > give a completely false signatu

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 3:57 PM Steven D'Aprano wrote: > Kind of like functions themselves :-) > > >>> (lambda x, y: 2*x + 3**y).__code__.co_code > b'd\x01|\x00\x14\x00d\x02|\x01\x13\x00\x17\x00S\x00' > > The internal structure of that co_code object is a mystery, it is not > part of the P

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-31 at 14:56:36 +1100, Chris Angelico wrote: > On Sun, Oct 31, 2021 at 2:43 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > > > On 2021-10-30 at 18:54:51 -0700, > > Brendan Barnwell wrote: > > > > > On 2021-10-30 18:29, Chris Angelico wrote: > > > > > > Right. That is a very real di

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 02:56:36PM +1100, Chris Angelico wrote: > Current versions of the PEP do not use the term "default value" when > referring to late binding (or at least, if I've made a mistake there, > then please point it out so I can fix it). I'm using the term "default > expression", or

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 03:43:25PM +1100, Chris Angelico wrote: > There is a downside: it is possible to flat-out lie to the > interpreter, by mutating bisect_left.__defaults__, so that help() will > give a completely false signature. >>> def func(arg="finest green eggs and ham"): ...

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 06:54:51PM -0700, Brendan Barnwell wrote: > I mean, here's another way to come at this. Suppose we have this > under the proposal (using some random syntax picked at random): > > def foo(a=1, b="two", c@=len(b), d@=a+c): > > You keep saying that c and

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 3:31 PM Steven D'Aprano wrote: > >>> inspect.signature(bisect.bisect_left) > > > I challenge anyone to honestly say that if that signature read: > > > > they would not be able to infer the meaning, or that Python would be a > worse language if the interpreter

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 3:16 PM Steven D'Aprano wrote: > > On Sun, Oct 31, 2021 at 12:29:18PM +1100, Chris Angelico wrote: > > > That's optional parameters. It's entirely possible to have optional > > parameters with no concept of defaults; it means the function can be > > called with or without t

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 06:52:33PM -0700, Christopher Barker wrote: > The point is: clearly specifying what's required, what's optional, and what > the defaults are if optional, is really, really useful -- and this PEP will > add another very handy feature to that. +1 Earlier I said that better

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 3:08 PM Brendan Barnwell wrote: > > On 2021-10-30 20:44, Chris Angelico wrote: > >> The default of every argument should be a first-class value. > >> That's > >> how things are now, and I think that's a very useful invariant to have. > >> If we want to break it

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 12:29:18PM +1100, Chris Angelico wrote: > That's optional parameters. It's entirely possible to have optional > parameters with no concept of defaults; it means the function can be > called with or without those arguments, and the corresponding > parameters will either be s

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 2:52 PM David Mertz, Ph.D. wrote: > > > On Sat, Oct 30, 2021, 11:03 PM Chris Angelico >> >> That's if you were to create a deferred *type*. An object which can be >> evaluated later. My proposal is NOT doing that, because there is no object >> that represents the unevalua

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 20:44, Chris Angelico wrote: The default of every argument should be a first-class value. That's how things are now, and I think that's a very useful invariant to have. If we want to break it we need a lot more justification than "I don't like typing if x is None". How

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 2:43 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-10-30 at 18:54:51 -0700, > Brendan Barnwell wrote: > > > On 2021-10-30 18:29, Chris Angelico wrote: > > > > Right. That is a very real difference, which is why there is a very > > > real difference between earl

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021, 11:03 PM Chris Angelico > That's if you were to create a deferred *type*. An object which can be > evaluated later. My proposal is NOT doing that, because there is no object > that represents the unevaluated expression. You can't pull that expression > out and evaluate it som

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 2:23 PM Brendan Barnwell wrote: > > On 2021-10-30 19:11, Chris Angelico wrote: > >> > I mean, here's another way to come at this. Suppose we have > >> > this under > >> >the proposal (using some random syntax picked at random): > >> > > >> >def foo(a=1, b="two", c

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 at 18:54:51 -0700, Brendan Barnwell wrote: > On 2021-10-30 18:29, Chris Angelico wrote: > > Right. That is a very real difference, which is why there is a very > > real difference between early-bound and late-bound defaults. But both > > are argument defaults. > > I don't 10

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 2:20 PM Rob Cliffe via Python-ideas wrote: > As for deferred evaluation objects: > First, Python already has various ways of doing deferred evaluation: > Lambdas > Strings, which can be passed to eval / exec / compile. > You can write decorator(s

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 19:11, Chris Angelico wrote: > I mean, here's another way to come at this. Suppose we have this under >the proposal (using some random syntax picked at random): > >def foo(a=1, b="two", c@=len(b), d@=a+c): > > You keep saying that c and d "are argument default" jus

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

Warning: Bear of Very Little Brain talking. Aren't we in danger of missing the wood for the (deferred-evaluation) trees here?     Late-bound-arguments defaults are USEFUL.  Being able to specify that a default value is a new empty list or a new empty set is USEFUL.  Plenty of people have ask

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 1:52 PM Steven D'Aprano wrote: > I believe that the PEP should declare that how the unevaluated defaults > are stored prior to evaluation is a private implementation detail. We > need an API (in the inspect module? as a method on function objects?) to > allow consumers to q

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 1:28 PM David Mertz, Ph.D. wrote: > > On Sat, Oct 30, 2021, 9:40 PM Chris Angelico wrote: >> >> > I'm not sure what I think of a general statement like: >> > >> > @do_later = fun1(data) + fun2(data) >> > >> > I.e. we expect to evaluate the first class object `do_later`

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 03:52:14PM -0700, Brendan Barnwell wrote: > The way you use the term "default value" doesn't quite work for me. > More and more I think that part of the issue here is that "hi=>len(a)" > we aren't providing a default value at all. What we're providing is > default

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021, 9:40 PM Chris Angelico wrote: > > I'm not sure what I think of a general statement like: > > > > @do_later = fun1(data) + fun2(data) > > > > I.e. we expect to evaluate the first class object `do_later` in some > other context, but only if requested within a program branc

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 7:03 PM Brendan Barnwell wrote: > > Right. That is a very real difference, which is why there is a very > > real difference between early-bound and late-bound defaults. But both > > are argument defaults. > > I don't 100% agree with that. > > I mean, here's

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 1:03 PM Brendan Barnwell wrote: > > On 2021-10-30 18:29, Chris Angelico wrote: > >> > What I am saying is that there is a qualitative difference > >> > between "I > >> >know now (at function definition time) what value to use for this > >> >argument if it's missing

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

I'm a bit confused as to why folks are making pronouncements about their support for this PEP before it's even finished, but, oh well. As for what seems like one major issue: Yes, this is a kind of "deferred" evaluation, but it is not a general purpose one, and that, I think, is the strength of t

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 18:29, Chris Angelico wrote: > What I am saying is that there is a qualitative difference between "I >know now (at function definition time) what value to use for this >argument if it's missing" and "I know now (at function definition time) >*what I will do* if this argumen

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021 at 6:32 PM Chris Angelico wrote: > We could just write every function with *args, **kwargs, and then do > all argument checking inside the function. We don't do this, because > it's the job of the function header to manage this. It's not the > function body's job to replace p

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 12:31 PM David Mertz, Ph.D. wrote: > > On Sat, Oct 30, 2021, 6:29 PM Chris Angelico wrote: >> >> > At first I thought it might be harmless, but nothing I really care about. >> > After the discussion, I think the PEP would be actively harmful to future >> > Python feature

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, Oct 30, 2021, 6:29 PM Chris Angelico wrote: > > At first I thought it might be harmless, but nothing I really care > about. After the discussion, I think the PEP would be actively harmful to > future Python features. > It's nothing more than an implementation detail. If you want to sugge

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 12:17 PM Brendan Barnwell wrote: > > On 2021-10-30 16:12, Chris Angelico wrote: > >> > Increasingly it seems to me as if you are placing inordinate > >> > weight on > >> >the idea that the benefit of default arguments is providing a "human > >> >readable" descripti

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 16:12, Chris Angelico wrote: > Increasingly it seems to me as if you are placing inordinate weight on >the idea that the benefit of default arguments is providing a "human >readable" description in the default help() and so on. And, to be >frank, I just don't care about tha

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 9:54 AM Brendan Barnwell wrote: > > On 2021-10-30 15:35, Chris Angelico wrote: > > Bear in mind that the status quo is, quite honestly, a form of white > > lie. In the example of bisect: > > > > def bisect(a, hi=None): ... > > def bisect(a, hi=>len(a)): ... > > > > neither

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 15:35, Chris Angelico wrote: Bear in mind that the status quo is, quite honestly, a form of white lie. In the example of bisect: def bisect(a, hi=None): ... def bisect(a, hi=>len(a)): ... neither form of the signature will actually say that the default value is the length of a. In

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, 30 Oct 2021, Brendan Barnwell wrote: I agree it seems totally absurd to add a type of deferred expression but restrict it to only work inside function definitions. Functions are already a form of deferred evaluation. PEP 671 is an embellishment to this mechanism for some of the code

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 9:20 AM Paul Moore wrote: > > On Sat, 30 Oct 2021 at 23:13, Brendan Barnwell wrote: > > > > On 2021-10-30 15:07, David Mertz, Ph.D. wrote: > > > I'm -100 now on "deferred evaluation, but contorted to be useless > > > outside of argument declarations." > > > > > > At first

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 9:17 AM Brendan Barnwell wrote: > > On 2021-10-26 20:15, Chris Angelico wrote: > > One of my goals here is to ensure that the distinction between > > early-bound and late-bound argument defaults is, again, orthogonal > > with everything else. You should be able to change "x

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sun, Oct 31, 2021 at 9:09 AM David Mertz, Ph.D. wrote: > > I'm -100 now on "deferred evaluation, but contorted to be useless outside of > argument declarations." > > At first I thought it might be harmless, but nothing I really care about. > After the discussion, I think the PEP would be acti

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On Sat, 30 Oct 2021 at 23:13, Brendan Barnwell wrote: > > On 2021-10-30 15:07, David Mertz, Ph.D. wrote: > > I'm -100 now on "deferred evaluation, but contorted to be useless > > outside of argument declarations." > > > > At first I thought it might be harmless, but nothing I really care > > about

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-26 20:15, Chris Angelico wrote: One of my goals here is to ensure that the distinction between early-bound and late-bound argument defaults is, again, orthogonal with everything else. You should be able to change "x=None" to "x=>[]" without having to wonder whether you're stopping your

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 2021-10-30 15:07, David Mertz, Ph.D. wrote: I'm -100 now on "deferred evaluation, but contorted to be useless outside of argument declarations." At first I thought it might be harmless, but nothing I really care about. After the discussion, I think the PEP would be actively harmful to future

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

I'm -100 now on "deferred evaluation, but contorted to be useless outside of argument declarations." At first I thought it might be harmless, but nothing I really care about. After the discussion, I think the PEP would be actively harmful to future Python features. On Sat, Oct 30, 2021, 3:57 PM E

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 10/26/2021 7:38 PM, Rob Cliffe via Python-ideas wrote: PS Can I echo Guido's plea that people don't derail this PEP by trying to shoehorn deferred-evaluation-objects (or whatever you want to call them) into it?  As Chris A says, that's a separate idea and should go into a separate PEP.  If

[Python-ideas] Re: Context managers in expressions

25.10.21 21:26, jcg.stu...@gmail.com пише: > I've been thinking for a while that it would be good to be able to use > context managers in an expression context, and I haven't been able to come up > with any arguments against it (although it may not be to everyone's taste) > and I can't see any s

[Python-ideas] Re: Context managers in expressions

Thanks, Mark... I had missed that aspect entirely. I think there might be a way round it... which actually was something I had been thinking of including in the same suggestion but thought was perhaps too obscure, but now I've realized it would integrate well with it. That is to have a value-retu

[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation

On 10/30/2021 10:40 AM, Chris Angelico wrote: And, seeing something in help(fn) largely necessitates that the source code be retained. I don't know of any other way to do it. If you say that the default argument is "len(a)", then that's what help() should say. "from __future__ import annotation

[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation

Hi Chris I like your questions. You ask: How would fn.__wibble__ be different from checks at the top of fn.__code__? They'd be in two different code blocks. I see a function call going as follows. 1. Process the supplied arguments in the usual way. 2. Create a new frame object and place it on the

[Python-ideas] Re: PEP 671 proof-of-concept: A less invasive implementation

On Sat, Oct 30, 2021 at 10:32 PM Jonathan Fine wrote: > I suggest that an implementation which provides additional flexibility in the > manner in which the code frame is initialised would be less invasive. > Necessarily, PEP 671 allows programmer supplied code to be used in the > 'initialisatio

[Python-ideas] Re: Take two -- PEP 671 proof-of-concept implementation

Side note: I've added operators and even a whole new builtin object for fun. ___ 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.

[Python-ideas] Re: Take two -- PEP 671 proof-of-concept implementation

> Still interested in coauthors who know CPython internals. That hasn't changed. I know some part of CPython internals, but I'm not quite sure how would a coauthor be recruited. I'm studying your implementation to understand more about how parsing to executing bytecode works in Python. __

[Python-ideas] PEP 671 proof-of-concept: A less invasive implementation

Hi One of the motives for PEP 671 is that the signature of a function fn, and hence the associated help(fn) is sometimes opaque regarding default values. I won't repeat the excellent examples already given. In the current implementation default values are handled outside the compiled code of the

[Python-ideas] Re: Take two -- PEP 671 proof-of-concept implementation

> Still interested in coauthors who know CPython internals. That hasn't changed. Should have been included since first mail. But this peaked my interest to dive into the C source Kind Regards, Abdur-Rahmaan Janhangeer about | blog

[Python-ideas] Take two -- PEP 671 proof-of-concept implementation

Second version of the POC implementation in response to feedback. On Fri, Oct 29, 2021 at 7:17 PM Chris Angelico wrote: > > https://github.com/Rosuav/cpython/tree/pep-671 > > So uhh... anyone who knows about the internals of CPython and wants to > join me on this, I would *really* appreciate coau