On 12/21/2017 6:36 AM, Ivan Levkivskyi wrote:
On 21 December 2017 at 11:22, Terry Reedy <tjre...@udel.edu
<mailto:tjre...@udel.edu>> wrote:
On 12/21/2017 4:22 AM, Eric V. Smith wrote:
On 12/21/2017 1:46 AM, Chris Barker wrote:
I suggest that it be clear in the docs, and ideally in the
PEP, that the dataclass decorator is using the *annotation"
syntax, and that the the only relevant part it uses is that
an annotation exists, but the value of the annotation is
essentially (completely?) ignored.
I think the PEP is very clear about this: "The dataclass
decorator examines the class to find fields. A field is defined
as any variable identified in __annotations__. That is, a
variable that has a type annotation. With two exceptions
described below, none of the Data Class machinery examines the
type specified in the annotation."
This seems clear enough. It could come after describing what a
dataclass *is*.
I agree the docs should also be clear about this.
So we should have examples like:
@dataclass
class C:
a: ... # field with no default
b: ... = 0 # filed with a default value
Then maybe:
@dataclass
class C:
a: "the a parameter" # field with no default
b: "another, different parameter" = 0.0 # field with a
default
Then the docs can go to say that if the user wants to
specify a type for use with a static type checking
pre-processor, they can do it like so:
@dataclass
class C:
a: int # integer field with no default
b: float = 0.0 # float field with a default
And the types will be recognized by type checkers such as mypy.
And I think the non-typed examples should go first in the docs.
Module some bike-shedding, the above seems pretty good to me.
For me, the three options for "don't care" have a bit different meaning:
* typing.Any: this class is supposed to be used with static type
checkers, but this field is too dynamic
* ... (ellipsis): this class may or may not be used with static type
checkers, use the inferred type in the latter case
* "field docstring": this class should not be used with static type checkers
Assuming this, the second option would be the "real" "don't care". If
this makes sense,
then we can go the way proposed in
https://github.com/python/typing/issues/276 and make ellipsis semantics
"official" in PEP 484.
(pending Guido's approval)
In
https://github.com/ericvsmith/dataclasses/issues/2#issuecomment-353918024,
Guido has suggested using `object`, which has the benefit of not needing
an import. And to me, it communicates the "don't care" aspect well
enough. I do understand the difference if you're using a type checker
(see for example
https://stackoverflow.com/questions/39817081/typing-any-vs-object), but
if you care about that, use typing.Any.
Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
