Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Implement pyright support via dataclass_transforms#796

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
hynek merged 19 commits intopython-attrs:mainfromasford:dataclass_transforms
May 5, 2021
Merged
Changes from1 commit
Commits
Show all changes
19 commits
Select commitHold shift + click to select a range
52d769c
Add __dataclass_transform__ decorator.
asfordApr 27, 2021
1891373
Add doc notes for pyright dataclass_transform support.
asfordApr 27, 2021
4f3787c
Fix docs build error.
asfordApr 28, 2021
bba9d7a
Expand docs on dataclass_transform
asfordApr 29, 2021
70e4286
Add changelog
asfordApr 29, 2021
41b4149
Fix docs build
asfordApr 29, 2021
8abde8a
Fix lint
asfordApr 29, 2021
2a4f8df
Add note on __dataclass_transform__ in .pyi
asfordApr 29, 2021
822722b
Add baseline test of pyright support via tox
asfordApr 29, 2021
55a0675
Add pyright tests to tox run configuration
asfordApr 29, 2021
7c21153
Fix test errors, enable in tox.
asfordApr 29, 2021
e8a4c0d
Fixup lint
asfordApr 29, 2021
6d10e30
Move pyright to py39
asfordApr 30, 2021
5fa3b2d
Add test docstring.
asfordApr 30, 2021
59714cf
Fixup docs.
asfordApr 30, 2021
68e86bf
Merge branch 'main' into dataclass_transforms
hynekMay 1, 2021
693e71b
Merge branch 'main' into dataclass_transforms
hynekMay 3, 2021
e63087b
Merge branch 'main' into dataclass_transforms
hynekMay 5, 2021
7876c40
Merge branch 'main' into dataclass_transforms
hynekMay 5, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
NextNext commit
Add __dataclass_transform__ decorator.
  • Loading branch information
@asford
asford committedApr 27, 2021
commit52d769c8db5d40b3c9104c451b59ec6752f227b4
14 changes: 14 additions & 0 deletionssrc/attr/__init__.pyi
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -86,6 +86,16 @@ else:
takes_self: bool = ...,
) -> _T: ...

# Static type inference support via __dataclass_transform__ implemented as per:
# https://github.com/microsoft/pyright/blob/1.1.135/specs/dataclass_transforms.md
# This annotation must be applied to all overloads of "define" and "attrs"
def __dataclass_transform__(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There should probably be an implementation of this somewhere right? Otherwise this won't be useful outside of attrs.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is a little strange, the decorator is just being used as a marker forpyright. The upstream spec specifies that the__dataclass_transform__ decorator is defined on a per-project basiseither in the a.py or.pyi source file, essentially as a compatibility layer until this is moved intotyping_extensions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Hmm. I'm a little concerned (ok not too much but it definitely feels weird) about having adef in the pyi file that doesn't exist in the .py file. It means that someone could try to use this function in their own code but mypy wouldn't warn them that it doesn't really exist. It would fail at runtime. Are we sure we don't want to put an implementation in _funcs.py or something?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

🤔 I've done a little test of this. Under the 1.1.135pyright implementation if we:

  • Define a__dataclass_transform__ decorator in__init__.pyi file.
  • Define a__dataclass_transform__ method in__funcs.py and import in__init__.py.

Then a custom annotation of the form has types inferred properly.

importattr@attr.__dataclass_transform__(fields=(attr.field,attr.attrib))defcustom_define(cls):returnattr.define(cls)@custom_defineclassCustom:a:int

However, given that this is a very early and provisional specification and implementation inpyright, adding a "surprisingly functional" shim inattrs introduces a potentially risky coupling. We've a choice between:

  1. An immediate and loud runtime failure if you "try to use" the attrs-internal__dataclass_transform__.pyi definition, that won't be caught static type checkers.
  2. A surprisingly functional form that "works" (a no-op a runtime, currently works at typingtime), but relies on unspecified upstream behavior.

Given how bleeding-edge this feature is I have a weakly held preference that we opt for 2 for this release to ensure that folks don't implictly rely on theimport attr.__dataclass_transform__ behavior and instead wait until the spec bakes enough for thedataclass_transform to show up intyping_extensions.

Of course, happy to reconsider.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Since this is only for pyright and doesn't currently get mypy to do the right thing (i.e. it doesn't tell mypy that this is an attrs class creator) perhaps it's best if we leave this only inside the pyi file. I might add a comment on here that says that this method doesn't actually exist at runtime.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Roger, comment added.

*,
eq_default: bool = True,
order_default: bool = False,
kw_only_default: bool = False,
field_descriptors: Tuple[Union[type, Callable[..., Any]], ...] = (()),
) -> Callable[[_T], _T]: ...

class Attribute(Generic[_T]):
name: str
Expand DownExpand Up@@ -276,6 +286,7 @@ def field(
on_setattr: Optional[_OnSetAttrArgType] = ...,
) -> Any: ...
@overload
@__dataclass_transform__(order_default=True, field_descriptors=(attrib, field))
def attrs(
maybe_cls: _C,
these: Optional[Dict[str, Any]] = ...,
Expand All@@ -301,6 +312,7 @@ def attrs(
field_transformer: Optional[_FieldTransformer] = ...,
) -> _C: ...
@overload
@__dataclass_transform__(order_default=True, field_descriptors=(attrib, field))
def attrs(
maybe_cls: None = ...,
these: Optional[Dict[str, Any]] = ...,
Expand All@@ -326,6 +338,7 @@ def attrs(
field_transformer: Optional[_FieldTransformer] = ...,
) -> Callable[[_C], _C]: ...
@overload
@__dataclass_transform__(field_descriptors=(attrib, field))
def define(
maybe_cls: _C,
*,
Expand All@@ -349,6 +362,7 @@ def define(
field_transformer: Optional[_FieldTransformer] = ...,
) -> _C: ...
@overload
@__dataclass_transform__(field_descriptors=(attrib, field))
def define(
maybe_cls: None = ...,
*,
Expand Down

[8]ページ先頭

©2009-2025 Movatter.jp