[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Chris Angelico
On Sat, 25 Jun 2022 at 11:56, Joao S. O. Bueno wrote: > > > > On Fri, Jun 24, 2022 at 10:05 PM Chris Angelico wrote: > > > > > Hmmm, I think possibly you're misunderstanding the nature of class > > slots, then. The most important part is that they are looked up on the > > *class*, not the

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Joao S. O. Bueno
On Fri, Jun 24, 2022 at 10:05 PM Chris Angelico wrote: > > Hmmm, I think possibly you're misunderstanding the nature of class > slots, then. The most important part is that they are looked up on the > *class*, not the instance; but there are some other quirks too: Sorry, no. I know how those

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Chris Angelico
On Sat, 25 Jun 2022 at 10:37, Joao S. O. Bueno wrote: > > > > On Fri, Jun 24, 2022 at 5:38 AM Chris Angelico wrote: > > > > On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno > > wrote: > > > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote: > > >> How much benefit would this be? You're

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Joao S. O. Bueno
On Fri, Jun 24, 2022 at 5:38 AM Chris Angelico wrote: > > On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno wrote: > > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote: > >> How much benefit would this be? You're proposing a syntactic construct > >> for something that isn't used all that

[Python-ideas] Re: dataclass field argument to allow converting value on init

2022-06-24 Thread Dexter Hill
I don't mind that solution although my concern is whether it would be confusing to have `init` have two different purposes depending on the argument. And, if `__post_init__` was overrided, which I would say it commonly is, that would mean the user would have to manually do the conversion, as

[Python-ideas] Re: Adopting better naming conventions (food for thought)

2022-06-24 Thread Paul Moore
That would break huge amounts of existing code. While better names might have been nice from the start, improving the naming is nowhere near enough benefit to justify such a disruptive change at this point in Python's development. Paul On Fri, 24 Jun 2022 at 22:47, abed...@gmail.com wrote: > >

[Python-ideas] Re: dataclass field argument to allow converting value on init

2022-06-24 Thread Dexter Hill
Didn't think about `attrs` but yes, the converter functionality at a glance looks exactly like I'd imagined it would function in dataclasses. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Adopting better naming conventions (food for thought)

2022-06-24 Thread abed...@gmail.com
I was reading some of Kevlin Henney's views on naming conventions , and I realized that, of the 65 classes that make up Python's built-in exceptions , only 8

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread David Mertz, Ph.D.
On Fri, Jun 24, 2022 at 10:52 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > We (not sure how much help I'll be, but I'm in) need to deal with > Chris A's point that a pure memoizing object doesn't help with the > mutable defaults problem. That is with > > def

[Python-ideas] Re: dataclass field argument to allow converting value on init

2022-06-24 Thread Steve Jorgensen
Steve Jorgensen wrote: > Simão Afonso wrote: > > On 2022-06-23 17:35:59, Steve Jorgensen wrote: > > What if, instead, the `init` parameter could accept either a boolean > > (as it does now) or a type? When given a type, that would mean that to > > created the property and accept the argument but

[Python-ideas] Re: dataclass field argument to allow converting value on init

2022-06-24 Thread Steve Jorgensen
Simão Afonso wrote: > On 2022-06-23 17:35:59, Steve Jorgensen wrote: > > What if, instead, the `init` parameter could accept either a boolean > > (as it does now) or a type? When given a type, that would mean that to > > created the property and accept the argument but pass the argument ti > >

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Chris Angelico
On Sat, 25 Jun 2022 at 00:54, Stephen J. Turnbull wrote: > > David Mertz, Ph.D. writes: > > On Fri, Jun 24, 2022 at 3:50 AM Stephen J. Turnbull > > wrote: > > > > I'm suggesting modified semantics where deferreds can be a proxy > > > object, whose normal reaction to *any* operation

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Stephen J. Turnbull
David Mertz, Ph.D. writes: > On Fri, Jun 24, 2022 at 3:50 AM Stephen J. Turnbull > wrote: > > I'm suggesting modified semantics where deferreds can be a proxy > > object, whose normal reaction to *any* operation (possibly > > excepting name binding) is > > > > 1. check for a

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread David Mertz, Ph.D.
On Fri, Jun 24, 2022 at 3:50 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > That's true in David's proposed semantics, where the runtime does that > check. I'm suggesting modified semantics where deferreds can be a > proxy object, whose normal reaction to *any* operation (possibly

[Python-ideas] Re: dataclass field argument to allow converting value on init

2022-06-24 Thread Simão Afonso
On 2022-06-23 17:35:59, Steve Jorgensen wrote: > What if, instead, the `init` parameter could accept either a boolean > (as it does now) or a type? When given a type, that would mean that to > created the property and accept the argument but pass the argument ti > `__post_init__` rather than using

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Chris Angelico
On Fri, 24 Jun 2022 at 17:51, Stephen J. Turnbull wrote: > Then the question is, why do we need syntax? Well, there's the PEP > 671 rationales for deferring function argument defaults. Which the OP hasn't actually explained in a way that works yet. A vanilla argument default value, with any

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Chris Angelico
On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno wrote: > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote: >> How much benefit would this be? You're proposing a syntactic construct >> for something that isn't used all that often, so it needs to be a >> fairly dramatic improvement in the cases

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Stephen J. Turnbull
Barry writes: > > On 23 Jun 2022, at 08:27, Stephen J. Turnbull > > wrote: > Interest idea that ref does not auto evaluate in all cases. > I was wondering about what the compile/runtime can do it avoid the costs > of checking for an evaluation. I think the main thing to do is to put the

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Steve Jorgensen
Steve Jorgensen wrote: > I think I have an idea how to do something like what you're asking with less > magic, and I think an example implementation of this could actually be done > in pure Python code (though a more performant implementation would need > support at the C level). > What if a

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread Joao S. O. Bueno
On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote: > On Fri, 24 Jun 2022 at 13:26, Joao S. O. Bueno > wrote: > > > > > > > > On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico wrote: > >> > >> On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno > wrote: > >> > > >> > Martin Di Paola wrote: > >> > >