Brendan Barnwell writes:
> As I've said before, the problem is that the benefit of this
> feature is too small to justify this large change to the status quo.
I don't disagree with this (but the whole thing is a YAGNI fvo "you" =
"me" so I'm uncomfortable agreeing as long "as x = x or defa
I have a suggestion for the implementation.
I think that Chris' current approach is to compile the late-bound
defaults in the function body. So if we have a function like this:
def func(a, b=early_expression, @c=late_expression):
block
the function code looks like this (after compil
On Sun, Oct 31, 2021 at 02:24:10PM +1100, Chris Angelico wrote:
> That last part is the most important here: it has to be evaluated *in
> the context of the function*. That's the only way for things like "def
> f(a, n=len(a)):" to be possible.
Agreed so far.
> Every piece of code in Python is e
On Sun, Oct 31, 2021 at 03:10:56PM +1100, Chris Angelico wrote:
> (Side point: The current reference implementation allows assignment
> expressions inside default argument expressions, mainly because I
> didn't go to the effort of blocking them. But if you ever ACTUALLY do
> this, then. *wat*)
Hi
I've just had a brainwave that may give an even less invasive
implementation of PEP 671. It relies on every function having a dict, as
provided by https://www.python.org/dev/peps/pep-0232/.
Consider:
def fn(a, b, c): pass
fn.__wibble__ = 123
fn.__wibble__ # Give 123, of course.
No
On Tue, Oct 26, 2021 at 08:59:51AM +0100, Rob Cliffe via Python-ideas wrote:
> And I don't understand what point you're making here. Yes, the walrus
> operator can appear in various places, how is that relevant? You could write
> def f(a := (b := c)):
> which might be a tad confusing but wou
On Sun, Oct 31, 2021 at 06:22:09PM +1100, Steven D'Aprano wrote:
[snip]
> Benefits:
If I have understood Chris correctly, there's another benefit. Replacing
the late bound defaults in the function object will no longer be a
misleading no-op that confuses introspection tools such as
inspect.sig
Actually, the "defer:"-syntax is really readable and searchable compared
to the cryptic comparison operator used in the proposal. Just thinking
towards "googleability".
Furthermore, the concept is even more general than parameter definition
of functions and methods. I guess a lot of people hav
On Sun, Oct 31, 2021 at 7:01 PM Jonathan Fine wrote:
>
> Hi
>
> I've just had a brainwave that may give an even less invasive implementation
> of PEP 671. It relies on every function having a dict, as provided by
> https://www.python.org/dev/peps/pep-0232/.
>
> Consider:
> def fn(a, b, c): p
On Sun, Oct 31, 2021 at 6:36 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 02:24:10PM +1100, Chris Angelico wrote:
>
> > That last part is the most important here: it has to be evaluated *in
> > the context of the function*. That's the only way for things like "def
> > f(a, n=len(a)):" to
On Sun, Oct 31, 2021 at 6:50 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 03:10:56PM +1100, Chris Angelico wrote:
>
> > (Side point: The current reference implementation allows assignment
> > expressions inside default argument expressions, mainly because I
> > didn't go to the effort of
On Sun, Oct 31, 2021 at 7:10 PM Steven D'Aprano wrote:
>
> On Tue, Oct 26, 2021 at 08:59:51AM +0100, Rob Cliffe via Python-ideas wrote:
>
> > And I don't understand what point you're making here. Yes, the walrus
> > operator can appear in various places, how is that relevant? You could write
> >
On Sun, Oct 31, 2021 at 9:24 PM Sven R. Kunze wrote:
>
> Actually, the "defer:"-syntax is really readable and searchable compared to
> the cryptic comparison operator used in the proposal. Just thinking towards
> "googleability".
>
Google's smarter than that. I've searched for symbols before an
Hi Chris
Again you ask good questions.
Q: How to find the bare string '#wibble'? It's optimised out during
compilation.
A: Very good. I didn't know that. For current Python we'll have to use a
different marker. For future Python we could change the compiler so that it
directly sets fn.__wibble__
On Sun, Oct 31, 2021 at 6:25 PM Steven D'Aprano wrote:
>
> I have a suggestion for the implementation.
>
> I think that Chris' current approach is to compile the late-bound
> defaults in the function body. So if we have a function like this:
>
> def func(a, b=early_expression, @c=late_expressi
On Sun, Oct 31, 2021 at 5:25 PM Chris Angelico wrote:
> I don't think this is a major problem. It's no worse than other things
> you can mess with, and if you do that sort of thing, you get only what
> you asked for; there's no way you can get a segfault or even an
> exception, as long as you use
On 10/30/2021 10:08 PM, Christopher Barker wrote:
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.
I think it's safe to say people are opposed to the PEP as it current
stands, not in it's final, as yet unseen,
On Sun, Oct 31, 2021 at 11:47 PM Eric V. Smith wrote:
>
> On 10/30/2021 10:08 PM, Christopher Barker wrote:
> > 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.
> I think it's safe to say people are opposed t
On Sun, 31 Oct 2021 at 12:45, Eric V. Smith wrote:
>
> I think it's safe to say people are opposed to the PEP as it current
> stands, not in it's final, as yet unseen, shape. But I'm willing to use
> other words that "I'm -1 on PEP 671". You can read my opposition as "as
> it currently stands, I'm
On Sat, 30 Oct 2021, Erik Demaine wrote:
Functions are already a form of deferred evaluation. PEP 671 is an
embellishment to this mechanism for some of the code in the function
signature to actually get executed within the body scope, *just like the body
of the function*.
I was thinking abo
On Mon, Nov 1, 2021 at 2:39 AM Erik Demaine wrote:
>
> On Sat, 30 Oct 2021, Erik Demaine wrote:
>
> > Functions are already a form of deferred evaluation. PEP 671 is an
> > embellishment to this mechanism for some of the code in the function
> > signature to actually get executed within the body
On Sun, Oct 31, 2021, 8:59 AM Chris Angelico
> def foo1(a=>[1,2,3], b=>len(a)):
> a.append(4)
> print(b)
>
> And what is the correct behaviour here?
>
> def foo2(a=defer [1,2,3], b=defer len(a)):
> a.append(4)
> print(b)
>
This is a nice example. I agree they are different in the
On Mon, Nov 1, 2021 at 2:59 AM David Mertz, Ph.D. wrote:
>
> On Sun, Oct 31, 2021, 8:59 AM Chris Angelico
>>
>> def foo1(a=>[1,2,3], b=>len(a)):
>> a.append(4)
>> print(b)
>>
>> And what is the correct behaviour here?
>>
>> def foo2(a=defer [1,2,3], b=defer len(a)):
>> a.append(4)
>>
On 31/10/2021 08:05, Steven D'Aprano wrote:
On Tue, Oct 26, 2021 at 08:59:51AM +0100, Rob Cliffe via Python-ideas wrote:
And I don't understand what point you're making here. Yes, the walrus
operator can appear in various places, how is that relevant? You could write
def f(a := (b := c)
On Mon, 1 Nov 2021, Chris Angelico wrote:
This is incompatible with the existing __get__ method, so it should
get a different name. Also, functions have a __get__ method, so you
definitely don't want to have everything that takes a callback run
into this. Let's say it's __delayed__ instead.
Ri
On 2021-10-31 05:57, Chris Angelico wrote:
Deferred expressions are not the same as late-bound argument defaults.
You keep saying this, but I still don't get the point. Descriptors are
not the same as properties, but we can implement properties with
descriptors. Decorators are not the same
On Mon, Nov 1, 2021 at 5:03 AM Brendan Barnwell wrote:
>
> On 2021-10-31 05:57, Chris Angelico wrote:
> > Deferred expressions are not the same as late-bound argument defaults.
>
> You keep saying this, but I still don't get the point. Descriptors
> are
> not the same as properties, but
On 31.10.21 12:34, Chris Angelico wrote:
Google's smarter than that. I've searched for symbols before and found
plenty of good results. For instance, I can search for information
about the @ sign before a function, or independently, for a @ b, and
get information about decorators or matrix multip
On 27/10/2021 08:56, Chris Angelico wrote:
On Wed, Oct 27, 2021 at 5:14 PM Brendan Barnwell wrote:
But I still think it's worth noticing
that the new syntax is not going to add a "full dimension". It is only
going to be useful for VERY SIMPLE late-bound default values. If the
late-bound d
On 31/10/2021 18:00, Brendan Barnwell wrote:
On 2021-10-31 05:57, Chris Angelico wrote:
Deferred expressions are not the same as late-bound argument defaults.
You keep saying this, but I still don't get the point. Descriptors
are not the same as properties, but we can implement properti
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
> PEP 671 will be USEFUL to Python programmers. We want it! (When do we
> want it? Now!)
>
This feels dishonest. I believe I qualify as a Python programmer. I started
using Python 1.4 in 1998. The large majority of my work life since th
On 2021-10-31 14:38, Rob Cliffe via Python-ideas wrote:
Wonderful!
+1,000,000.
So are you going to write a PEP explaining exactly how you propose to
implement deferred expressions and how they would be used? And perhaps
provide a reference implementation? Then we can see how it works, and
how i
On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D. wrote:
> I am not on the SC, so indeed I won't make the decision. But I *will*
> continue to teach Python. New syntax adds a burden to learners, and it should
> not be introduced without sufficient benefit to merit that burden. This
> proposal d
On 31/10/2021 21:54, David Mertz, Ph.D. wrote:
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
PEP 671 will be USEFUL to Python programmers. We want it! (When
do we want it? Now!)
This feels dishonest. I believe I qualify as a Python programmer. I
started using Python 1
On Sun, Oct 31, 2021, 6:11 PM Chris Angelico
> On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D.
> wrote:
> > I am not on the SC, so indeed I won't make the decision. But I *will*
> continue to teach Python. New syntax adds a burden to learners, and it
> should not be introduced without sufficien
On 2021-10-31 15:08, Chris Angelico wrote:
On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D.
wrote:
I am not on the SC, so indeed I won't make the decision. But I
*will* continue to teach Python. New syntax adds a burden to
learners, and it should not be introduced without sufficient
benefit to
On Sun, Oct 31, 2021 at 09:20:32PM +0100, Sven R. Kunze wrote:
> People on the threads said that they simply want to initialize an empty
> list [] by a desire to avoid the None scheme.
>
> I would rather solve those kind of issues than help to squeeze
> complicated logic into default parameters
On Mon, Nov 1, 2021 at 11:26 AM Steven D'Aprano wrote:
> What sort of testing and maintenance perspective are you referring to?
> Testing and maintenance of the Python interpreter? Or your own code?
>
> If it is your own code then this proposal will have no effect on your
> testing and maintenance
On Sun, Oct 31, 2021 at 4:50 AM Eric V. Smith wrote:
>
> 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
On 1/11/21 4:59 am, David Mertz, Ph.D. wrote:
b = b
I don't want to live in a universe where this could be anything
other than a no-op in Python.
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to py
On Mon, Nov 1, 2021 at 5:15 PM Greg Ewing wrote:
>
> On 1/11/21 4:59 am, David Mertz, Ph.D. wrote:
> > b = b
>
> I don't want to live in a universe where this could be anything
> other than a no-op in Python.
>
Be careful what you say: there are some technicalities. If you mean
that it won't
41 matches
Mail list logo
