Given I started this thread from a perspective of this is a feature that I would like because I need it, it feels a little dismissive to take attrs not having the feature to mean "there's no reason to try to implement this."On Mon, Jan 29, 2018 at 11:05 AM Guido van Rossum <guido@python.org> wrote:I think that settles it -- there's no reason to try to implement this.On Mon, Jan 29, 2018 at 10:51 AM, George Leslie-Waksman <waksman@gmail.com> wrote:attrs' seems to also not allow mandatory attributes to follow optional one:In [14]: @attr.s...: class Baz:...: a = attr.ib(default=attr.Factory(list)) ...: b = attr.ib()...:------------------------------------------------------------ --------------- ValueError Traceback (most recent call last)<ipython-input-14-2c63f3f229a5> in <module>() ----> 1 @attr.s2 class Baz:3 a = attr.ib(default=attr.Factory(list)) 4 b = attr.ib()5/Users/waksman/.pyenv/versions/3.6.1/envs/temp/lib/ python3.6/site-packages/attr/_ make.py in attrs(maybe_cls, these, repr_ns, repr, cmp, hash, init, slots, frozen, str, auto_attribs) 700 return wrap701 else:--> 702 return wrap(maybe_cls)703704/Users/waksman/.pyenv/versions/3.6.1/envs/temp/lib/ python3.6/site-packages/attr/_ make.py in wrap(cls) 669 raise TypeError("attrs only works with new-style classes.")670--> 671 builder = _ClassBuilder(cls, these, slots, frozen, auto_attribs)672673 if repr is True:/Users/waksman/.pyenv/versions/3.6.1/envs/temp/lib/ python3.6/site-packages/attr/_ make.py in __init__(self, cls, these, slots, frozen, auto_attribs) 369370 def __init__(self, cls, these, slots, frozen, auto_attribs):--> 371 attrs, super_attrs = _transform_attrs(cls, these, auto_attribs)372373 self._cls = cls/Users/waksman/.pyenv/versions/3.6.1/envs/temp/lib/ python3.6/site-packages/attr/_ make.py in _transform_attrs(cls, these, auto_attribs) 335 "No mandatory attributes allowed after an attribute with a "336 "default value or factory. Attribute in question: {a!r}"--> 337 .format(a=a)338 )339 elif had_default is False and \ValueError: No mandatory attributes allowed after an attribute with a default value or factory. Attribute in question: Attribute(name='b', default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True, metadata=mappingproxy({}), type=None, converter=None)On Fri, Jan 26, 2018 at 1:44 PM Guido van Rossum <guido@python.org> wrote:What does attrs' solution for this problem look like?On Fri, Jan 26, 2018 at 11:11 AM, George Leslie-Waksman <waksman@gmail.com> wrote:Even if we could inherit the setting, I would think that we would still want to require the code be explicit. It seems worse to implicitly require keyword only arguments for a class without giving any indication in the code.As it stands, the current implementation does not allow a later subclass to be declared without `keyword_only=True` so we could handle this case by adding a note to the `TypeError` message about considering the keyword_only flag.How do I got about putting together a proposal to get this into 3.8?
--GeorgeOn Thu, Jan 25, 2018 at 5:12 AM Eric V. Smith <eric@trueblade.com> wrote:I'm not completely opposed to this feature. But there are some cases to
consider. Here's the first one that occurs to me: note that due to the
way dataclasses work, it would need to be used everywhere down an
inheritance hierarchy. That is, if an intermediate base class required
it, all class derived from that intermediate base would need to specify
it, too. That's because each class just makes decisions based on its
fields and its base classes' fields, and not on any flags attached to
the base class. As it's currently implemented, a class doesn't remember
any of the decorator's arguments, so there's no way to look for this
information, anyway.
I think there are enough issues here that it's not going to make it in
to 3.7. It would require getting a firm proposal together, selling the
idea on python-dev, and completing the implementation before Monday. But
if you want to try, I'd participate in the discussion.
Taking Ivan's suggestion one step further, a way to do this currently is
to pass init=False and then write another decorator that adds the
kw-only __init__. So the usage would be:
@dataclass
class Foo:
some_default: dict = field(default_factory=dict)
@kw_only_init
@dataclass(init=False)
class Bar(Foo):
other_field: int
kw_only_init(cls) would look at fields(cls) and construct the __init__.
It would be a hassle to re-implement dataclasses's _init_fn function,
but it could be made to work (in reality, of course, you'd just copy it
and hack it up to do what you want). You'd also need to use some private
knowledge of InitVars if you wanted to support them (the stock
fields(cls) doesn't return them).
For 3.8 we can consider changing dataclasses's APIs if we want to add this.
Eric.
On 1/25/2018 1:38 AM, George Leslie-Waksman wrote:
> It may be possible but it makes for pretty leaky abstractions and it's
> unclear what that custom __init__ should look like. How am I supposed to
> know what the replacement for default_factory is?
>
> Moreover, suppose I want one base class with an optional argument and a
> half dozen subclasses each with their own required argument. At that
> point, I have to write the same __init__ function a half dozen times.
>
> It feels rather burdensome for the user when an additional flag (say
> "kw_only=True") and a modification to:
> https://github.com/python/cpython/blob/master/Lib/ thatdataclasses.py#L294
> inserted `['*']` after `[self_name]` if the flag is specified could
> ameliorate this entire issue.
>
> On Wed, Jan 24, 2018 at 3:22 PM Ivan Levkivskyi <levkivskyi@gmail.com
> <mailto:levkivskyi@gmail.com>> wrote:
>
> It is possible to pass init=False to the decorator on the subclass
> (and supply your own custom __init__, if necessary):
>
> @dataclass
> class Foo:
> some_default: dict = field(default_factory=dict)
>
> @dataclass(init=False) # This works
> class Bar(Foo):
> other_field: int
>
> --
> Ivan
>
>
>
> On 23 January 2018 at 03:33, George Leslie-Waksman
> <waksman@gmail.com <mailto:waksman@gmail.com>> wrote:
>
> The proposed implementation of dataclasses prevents defining
> fields with defaults before fields without defaults. This can
> create limitations on logical grouping of fields and on inheritance.
>
> Take, for example, the case:
>
> @dataclass
> class Foo:
> some_default: dict = field(default_factory=dict)
>
> @dataclass
> class Bar(Foo):
> other_field: int
>
> this results in the error:
>
> 5 @dataclass
> ----> 6 class Bar(Foo):
> 7 other_field: int
> 8
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/ site-packages/dataclasses.py
> in dataclass(_cls, init, repr, eq, order, hash, frozen)
> 751
> 752 # We're called as @dataclass, with a class.
> --> 753 return wrap(_cls)
> 754
> 755
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/ site-packages/dataclasses.py
> in wrap(cls)
> 743
> 744 def wrap(cls):
> --> 745 return _process_class(cls, repr, eq, order,
> hash, init, frozen)
> 746
> 747 # See if we're being called as @dataclass or
> @dataclass().
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/ site-packages/dataclasses.py
> in _process_class(cls, repr, eq, order, hash, init, frozen)
> 675 # in __init__. Use
> "self" if possible.
> 676 '__dataclass_self__' if
> 'self' in fields
> --> 677 else 'self',
> 678 ))
> 679 if repr:
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/ site-packages/dataclasses.py
> in _init_fn(fields, frozen, has_post_init, self_name)
> 422 seen_default = True
> 423 elif seen_default:
> --> 424 raise TypeError(f'non-default argument
> {f.name <http://f.name>!r} '
> 425 'follows default argument')
> 426
>
> TypeError: non-default argument 'other_field' follows default
> argument
>
> I understand that this is a limitation of positional arguments
> because the effective __init__ signature is:
>
> def __init__(self, some_default: dict = <something>,
> other_field: int):
>
> However, keyword only arguments allow an entirely reasonable
> solution to this problem:
>
> def __init__(self, *, some_default: dict = <something>,
> other_field: int):
>
> And have the added benefit of making the fields in the __init__
> call entirely explicit.
>
> So, I propose the addition of a keyword_only flag to the
> @dataclass decorator that renders the __init__ method using
> keyword only arguments:
>
> @dataclass(keyword_only=True)
> class Bar(Foo):
> other_field: int
>
> --George Leslie-Waksman
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org <mailto:Python-ideas@python.org >
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
----Guido van Rossum (python.org/~guido)
----Guido van Rossum (python.org/~guido)