That's clever, I'm a fan of that syntax. Quick question on it though - If you
provide a `default` or `default_factory` to `field`, as well as `init_using`,
how would that be handled? I'm thinking, `default_factory` would be made
mutually exclusive, so you couldn't use it but `default` would
Dexter Hill wrote:
> Steve Jorgensen wrote:
> > Would we want something more general that could deal with cases where the
> > input does not have a 1-to-1 mapping to the field that differ only,
> > perhaps, in type hint? What if we want 1 argument to initializes 2
> > properties or vice verse,
Steve Jorgensen wrote:
> Would we want something more general that could deal with cases where the
> input does not have a 1-to-1 mapping to the field that differ only, perhaps,
> in type hint? What if we want 1 argument to initializes 2 properties or vice
> verse, etc.?
That's definitely an
I think we are saying the same thing. I don't think this would require
another parameter if type checkers are capable of inferring the type
from the parameter to the function to be called on init.
On Wed, 2022-06-29 at 21:26 +, Steve Jorgensen wrote:
> Paul Bryan wrote:
> > Could the type
Paul Bryan wrote:
> Could the type hint for the __init__ parameter be inferred from the
> (proposed) init_fn's own parameter type hint itself?
> On Tue, 2022-06-28 at 16:39 +, Steve Jorgensen wrote:
I think I was already suggesting that possibility "an optional argument to
`InitFn` or maybe
Could the type hint for the __init__ parameter be inferred from the
(proposed) init_fn's own parameter type hint itself?
On Tue, 2022-06-28 at 16:39 +, Steve Jorgensen wrote:
> Dexter Hill wrote:
> > Ah right I see what you mean. In my example I avoided the use of
> > `__init__` and
Dexter Hill wrote:
> Ah right I see what you mean. In my example I avoided the use of `__init__`
> and specifically `__post_init__` as (and it's probably a fairly uncommon use
> case), in my actual project, `__post_init__` is defined on a base class, and
> inherited by all other classes, and I
Ah right I see what you mean. In my example I avoided the use of `__init__` and
specifically `__post_init__` as (and it's probably a fairly uncommon use case),
in my actual project, `__post_init__` is defined on a base class, and inherited
by all other classes, and I wanted to avoid overriding
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
>
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:
> 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
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
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
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
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
> >
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
This is what attrs' converter functionality is, right?
https://www.attrs.org/en/stable/init.html#converters
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Sorry for typos.
___
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.org/
Message archived at
Dexter Hill wrote:
> The idea is to have a `default_factory` like argument (either in the `field`
> function, or a new function entirely) that takes a function as an argument,
> and that function, with the value provided by `__init__`, is called and the
> return value is used as the value for
Interesting point, it's not something I thought of. One solution as mentioned
by Simão, and what I had in mind, is to pull the type from the first parameter
of the function. We know that the function is always going to have minumum 1
parameter, and the value is always passed as the first
On 2022-06-23 00:03:03, Paul Bryan wrote:
> What type hint will be exposed for the __init__ parameter? Clearly,
> it's not a `str` type in your example; you're passing it an `int` value
> in your example. Presumably to overcome this, you'd need yet another
> `field` function parameter to provide
What type hint will be exposed for the __init__ parameter? Clearly,
it's not a `str` type in your example; you're passing it an `int` value
in your example. Presumably to overcome this, you'd need yet another
`field` function parameter to provide the type hint for the `__init__`
param?
On Wed,
22 matches
Mail list logo
