-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type annotation required? #2
Comments
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
To get it to work, I have to import 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 |
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
<#2 (comment)>,
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 |
That's a fair cop.
…On Dec 26, 2017 02:04, "Ivan Levkivskyi" ***@***.***> 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
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACwrMgXWKsZLa8y0QEx0rgNLTMoM4BGQks5tELangaJpZM4Nhwpf>
.
|
I was going to suggest That'd be less complicated than my suggestion of a |
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" ***@***.***> 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
<#2 (comment)>,
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('_')]
The text was updated successfully, but these errors were encountered: