Chris Angelico writes:
> So the only way around it would be to make the defer keyword somehow
> magical when used in a function signature, which kinda defeats the
> whole point about being able to reuse another mechanic to achieve
> this.
The defer keyword is already magical. Overloading it
On 2022-06-21 13:53, David Mertz, Ph.D. wrote:
Here is a very rough draft of an idea I've floated often, but not with
much specification. Take this as "ideas" with little firm commitment to
details from me. PRs, or issues, or whatever, can go to
On Sun, 26 Jun 2022 at 04:41, Brendan Barnwell wrote:
> In contrast, what I would want out of deferred evaluation is precisely
> the ability to evaluate the deferred expression in the *evaluating*
> scope (not the definition scope) --- or in a custom provided namespace.
> Whether this
Dexter Hill wrote:
> 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
Do you mind providing a little example of what you mean? I'm not sure I 100%
understand what your use of `__post_init__` is. In my mind, it would be
something like:
```py
@dataclass
class Foo:
x: str = field(init=int, converter=chr)
# which converts to
class Foo:
def __init__(self, x:
Dexter Hill wrote:
> Do you mind providing a little example of what you mean? I'm not sure I 100%
> understand what your use of `__post_init__` is. In my mind, it would be
> something like:
> ```py
> @dataclass
> class Foo:
> x: str = field(init=int, converter=chr)
> # which converts to
>
