Add support for marking classes `typing.final`
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- python
調査の方向性
Start by reviewing the public frozen, define, and mutable decorator APIs and the question of how they should interact with typing.final. The issue leaves defaults, backward compatibility, subclassing behavior, and deprecation options unresolved. Done would require an agreed design before implementation scope can be defined.
索引モデルが issue の本文から書いたものです。
説明
I am filing the below not really having through details, though I at least don't see this mentioned in any other issue, hence splatting it out :). Spicy takes I'm sure coming below as I'm sure part of this rests on how much each of us tolerates inheritance.
Should attrs have a way to apply typing.final to its classes so that they're easier to mark as "don't subclass"? E.g. a final= argument to frozen / define / mutable?
Obviously stacking the two decorators works, so the motivation I guess for me personally is just "I always want final for basically any class I expose", so if attrs had this it's one less thing to forget. What I do now is usually things at runtime, which don't use final() at all, but given I just realized I should probably add final() too so that users who do rely on their type checkers see a warning, that made me wonder whether that half is something general enough to be here.
If it were an argument to define, defaulting to True obviously breaks backwards compatibility. Perhaps doing it for frozen at least is justifiable? Or at least desirable with a deprecation warning for subclassing in the interim?
Any thoughts on how reasonable that sounds?
- 主要言語
- Python
- スター
- 5.9k
- フォーク
- 501
- 平均マージ
- 3日 5分
- マージ済み PR（30日）
- 4
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
python-attrs/attrs のほかの issue
-
Docs: `attrs.filters` is missing stated examples対応中かも @feiiiiii5 が 17 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
python-attrs/attrs#1627 ·
メンテナーはふだん 1 日以内に返信
-
slots declared on attrs-decorated class are ignored/lost対応中かも @anshurajbisoyi98-ctrl が 9 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
python-attrs/attrs#1637 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
python-attrs/attrs#1620 ·
メンテナーはふだん 1 日以内に返信
-
Incorrect annotation for forward reference in generated constructor対応中かも @MohammedAnasNathani が 74 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
python-attrs/attrs#1596 · コメント 2 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Decorated functions do not work with inheritance対応中かも @sb123sb123 が 21 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
python-attrs/attrs#1549 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
python-attrs/attrs の issue をすべて見る
似ている issue
-
SSM GetParameter throttling during concurrent workflow launches対応中かも @alexiswl が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
-
[Bug] Dev image build fails: `npm install` in the root Dockerfile runs out of memory (exit 134)対応中かも @andest01 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
enhancement good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
pesu-dev/discord_bot#97 ·
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
gradio-app/gradio#13964 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 93/100
BSData/horus-heresy-3rd-edition#3232 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信