Closed ericvsmith closed 7 years ago
Agreed. y is not a field.
Thanks, Guido.
This requirement tripped me up. Consider the following code:
from dataclasses import dataclass, field
@dataclass
class Wrapper:
value = field()
I assumed I could use it like:
instance = Wrapper(1)
But because the value = field()
declaration does not have a type annotation, Wrapper(1)
raises a TypeError.
TypeError: __init__() takes 1 positional argument but 2 were given
To get it to work, I have to import typing
and use Any
:
from typing import Any
@dataclass
class Wrapper:
value: Any = field()
which adds unneeded verbosity to unannotated code. It would be nice if unannotated attributes on a dataclass
decorated declaration that are instances of dataclasses.Field
would be treated as fields on the data class.
While there seems to be pressure building against this requirement I would like to resist. You don't have to import typing, you can use 'object' for the type.
On Dec 25, 2017 18:59, "Tommi Kaikkonen" notifications@github.com wrote:
This requirement tripped me up. Consider the following code:
from dataclasses import dataclass, field @dataclassclass Wrapper: value = field()
I assumed I could use it like:
instance = Wrapper(1)
But because the value = field() declaration does not have a type annotation, Wrapper(1) raises a TypeError.
TypeError: init() takes 1 positional argument but 2 were given
To get it to work, I have to import typing and use Any:
from typing import Any @dataclassclass Wrapper: value: Any = field()
which adds unneeded verbosity to unannotated code. It would be nice if unannotated attributes on a dataclass decorated declaration that are instances of dataclasses.Field would be treated as fields on the data class.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/ericvsmith/dataclasses/issues/2#issuecomment-353903594, or mute the thread https://github.com/notifications/unsubscribe-auth/ACwrMuuCm4hnnjlcSLm8Z_1spozNe21Iks5tEFMUgaJpZM4Nhwpf .
@gvanrossum I however think it is better to give a clear error in this case, not just silently ignore the field
s that are not in __annotations__
.
That's a fair cop.
On Dec 26, 2017 02:04, "Ivan Levkivskyi" notifications@github.com wrote:
@gvanrossum https://github.com/gvanrossum I however think it is better to give a clear error in this case, not just silently ignore the fields that are not in annotations.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ericvsmith/dataclasses/issues/2#issuecomment-353942347, or mute the thread https://github.com/notifications/unsubscribe-auth/ACwrMgXWKsZLa8y0QEx0rgNLTMoM4BGQks5tELangaJpZM4Nhwpf .
I was going to suggest object
earlier in the python-dev thread but wasn't sure how object differs from Any in meaning. If you're good with object
, so am I.
That'd be less complicated than my suggestion of a Data = "typing.any"
alias in the dataclasses module.
Well, object is not great, 'typing.Any' is better if you are going to use mypy but don't want to constrain the types. But the use case being discussed seems to be people who absolutely don't want to import typing and don't want to declare types. Unless other conventions I have seen proposed, using object is at least technically correct and mypy won't complain about it in one direction. (It will complain if you use it in a context where a more specific type is expected, but it will accept all constructor calls as valid.)
On Dec 26, 2017 9:32 PM, "Gregory P. Smith" notifications@github.com wrote:
I was going to suggest object earlier in the python-dev thread but wasn't sure how object differs from Any in meaning. If you're good with object, so am I.
That'd be less complicated than my suggestion of a Data = "typing.any" alias in the dataclasses module.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ericvsmith/dataclasses/issues/2#issuecomment-354050343, or mute the thread https://github.com/notifications/unsubscribe-auth/ACwrMsvcevWiKxHwhaG03RS77R4J0FoIks5tEchDgaJpZM4Nhwpf .
For:
Is y a field? What are the params to init()? Just x? Or x and y?
dataclass doesn't need to look at annotations, so there's no technical reason they'd be required.
My personal preference is to require them. That is, drive field discovery from
__annotations__
, not something like[name for name in C.__dict__ if not name.startswith('_')]