はてなブックマーク

今朝、PEP 647 (User-Defined Type Guards) が Accepted になったというPRを見かけました。 そこで、今回は PEP 647 を読んでみようと思います。 概要 型チェッカーツールでは type narrowing と呼ばれる手法を使って、プログラム内で型情報をより正確に決定しています。 以下の例では if文と is None を利用して、自動的に if 文の中の型が絞り込まれます。 def func(val: Optional[str]): # "is None" type guard if val is not None: # Type of val is narrowed to str ... else: # Type of val is narrowed to None ... 他にも isinstance() など、いくつかの判定で type

今週の火曜日、PEP 634〜636 の 3本の PEP が Accept されました。 お。Accept になってる / PEP 634/635/636: Accept! by brandtbucher · Pull Request #1807 · python/peps https://t.co/KTeJJQylEe — tk0miya (@tk0miya) February 9, 2021 この 3本の PEP は、去年の 6月に Python3 に提案されたばかりのパターンマッチング構文を調べてみた として紹介した PEP 622 の後継となる提案です。 今回は約 7ヶ月の議論を経て、Python 3.10 に採用されることが決定したこの Structural Pattern Matching について見ていきましょう。 3本立て Structural Pattern Matchi

追記: この記事から8ヶ月後に、パターンマッチ構文は Python に採用されることが決まりました。 PEP 634, 635, 636 (Structural Pattern Matching) を読んだよメモ では最新情報をもとに記事を再構成しています。 昨夜、突如 PEP 622 (Structural Pattern Matching) が python/peps に投稿されました。 python 系のメーリングリストを追いかけていない僕にとっては突然の大物 Draft の登場で、大混乱です。 野心的な PEP が出てきた。なにこれやばい。あとでじっくり読む。 / PEP 622 -- Structural Pattern Matching | https://t.co/HIipocP5Vt https://t.co/o0OUN6BqgH — tk0miya (@tk0miya)

Microsoft の Python 向け型チェッカーの pyright が最新の仕様に対応していると聞いて README を流し読みしていたら、今までウォッチしていなかった PEP 604 (Complementary syntax for Union[]) というのがリストアップされていたので目を通してみました。 ちなみに次の記事で PEP-612 についても書く予定です。 概要 毎回 Union[int, str] って書くのうざくない? Scala みたいに int | str って書けるようにしようよ 型アノテーションだけじゃなくて、 isinstance() や issubclass() でも使えるようにしようよ アプローチ 型同士を | でつなぐと型集合をつくれるようにする 以上。 例 PEP にあるサンプルを見ると一目瞭然なので説明は省きます。 # in place of

皆さん、普段 Python でコードを書くときはちゃんと型を書いてますよね? まだ型の書き方を知らない場合は Software Design 2020年 5月号の『Python でも型チェックしよう』を読むといいと思いますよ (宣伝)。 レビューのお手伝いをした『Python でも型チェックしよう』(by @t2y)が掲載されているSDが発売されました。型ヒントを使ってみたい方におすすめです。また、3.8で導入された Protocolなども紹介されており、すでに使っている方にもお勧め！ / Software Design 2020年5月号 https://t.co/JL5GgO0mcq — tk0miya (@tk0miya) April 18, 2020 私はコードに型をつけ始めておおよそ 3年ぐらいになるのですが、いまでは型がないと落ち着かなくなっています。 コード規模がある程度大きく

__origin__ という属性がどこからやってきたのを調べていたところ、 PEP 585 -- Type Hinting Generics In Standard Collections という PEP を見つけたので、本来の目的を忘れて流し読みしてました。まだ Draft ステータスですので、今後採用されるかどうかはわかりませんが、自分の理解をメモに残しておきます。 概要 これまでの型アノテーションでは、コレクションを表現するのに専用の型を使っていた (typing.List や typing.Dict など) コレクションの実装クラスと型クラスを統合し、標準のコレクションクラス(list や dict など)で型アノテーションできるようにしよう いずれ typing 配下のジェネリックコレクション型は廃止したい 用語 Generic パラメータ化可能な型。一般的にはコンテナを指す。

先ほど Sphinx-2.4.0 をリリースしました。 Sphinx は 2ヶ月ごとの定期リリースを目指しているので、大体予定通りのリリースです。 2.4.0 では autodoc まわりの機能が大きく改善されました。この記事ではその改善点についてまとめたいと思います。 変数アノテーションへの対応 autodoc: Support type annotations for variables #7051: autodoc: Support instance variables without defaults (PEP-526) これまで、コード内の変数アノテーションはドキュメント化されていなかったのですが、2.4 からはドキュメントに出力されるようになりました。 いまや型情報は規模の大きいプログラムを書くのに欠かせない情報となっています。型情報をアノテーションすることは、あなたと開発チー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 気がついたら IANA の markdown variants に項目が増えてる。皆さん知ってましたか。 / Markdown Variants https://t.co/Hf2UNFlnIm — tk0miya (@tk0miya) February 3, 2020 週末に Markdown の記事を書いた流れなのか、普段まったく見向きもしない IANA の Markdown variants リストをふと開いてみました。記憶では最後にこのページにやってきたのは RFC が採用された頃ですから、4年ぶりの再訪です。 すると、なんという

のんびりしていたらこんなメンションをもらっていたので、ちょっとまとめてみようと思います。 そろそろ @tk0miya さんがアップしてくる頃。GFMはspecかっちりしてるんでしたっけ(markdown全く詳しくない — Aki Ariga (@chezou) February 1, 2020 かっちりしている? この記事を読んでいる皆さんは Markdown の歴史に精通していると思うので、古い部分はざっくり割愛してしまいますが、オリジナルの Markdown は かっちりしていない ことで有名なマークアップ言語です。 必要最低限のマークアップ要素は規定されていて HTML への変換ツールも完成していた Markdown ですが、マークアップ言語の言語仕様としては貧弱で、インデントのルールやインライン要素をネストしたときの挙動、空行の有無による解釈の違い、などなど、細かい部分のルールにつ

少し前に Slack の UI が変更され、ビジュアルエディタになりましたね。ビジュアルエディタが出てくるのは一般ユーザーが増えてきた証左ではないかと思うものの、テキストマークアップに慣れ親しんだ身にはあまり便利ではないですし、仕上がってきたエディタの完成度を見てウッとなった人も少なくはないでしょう。 さて、そんな変化の中で、qiita だったか twitter だかで「Slack の Markdown」という表記を目にする機会がありました。Markdown の仕様を調べているものとしては、Slack の記法と Markdown は似てはいるが異なるものとコメントせざるを得ないのですが、一方で似ているという感覚には首肯せざるを得ないものがあります。 その違和感について整理してみたいと思います。 Slack の記法を見てみる まずは Slack のマニュアルを見てみましょう。メッセージの書式