書き直した理由は幾つかあるのですが大きく2つです。commentを見るより、型アノテーションを見たほうが良い以前から個人的にテーマとしている「やがて消えてなくなるライブラリ」という概念を実装できそうだったため書き直しのタイミングで幾つか過剰に保持していた機能も一部捨て去りました(ミドルウェア的な機能など)。commentの形式の方が主流だった記憶があります。これを実装した当時もオプションという扱いで、あまりアピールしたい機能として実装はしていませんでした。いうのも、基本的には、実装の初期段階の試行錯誤の間で、消しては作ってを繰り返し、最終的には残るかどうかもわからないコマンド(スクリプト)の使用感を試すというようなタイミングで、横着をするためにこのライブラリがあるわけなのですが。まじめにsphinx形式のドキュメント文字列を書いている時点で、コマンドラインパーサーの定義くらい書いてしまうことが多いからです。これは自分だけかもしれませんが、試行錯誤のコマンドラインパーサーの定義(argparse)の方がドキュメント文字列より先になることが多いです。まじめにコマンドとして作り込みたいという場合には、それこそ自分でコードを書くと言うことが多かったりします。過去のバージョンで冒頭に紹介したコードと同様のことを行う例は以下です。suffix=suffix))ちなみに、上の例からわかると思いますが、以前のバージョン(0.4.4)と現在のバージョン(2.0.0)では機能に違いがあります。引数毎のコメントをつけることができなくなっています。機能が増えた面もあって、デフォルト引数なしに、数値として扱うことができるようになっています(記憶が確かなら過去の版はsphinxのautodoc用のコメントのうちの型定義の読み込みは省略していたような記憶があります)。以前のバージョンではデフォルト引数の型を見て数値や論理値として扱うかどうか判断していた記憶があります。以前から個人的にテーマとしている「やがて消えてなくなるライブラリ」という概念を実装できそうだったためどちらかと言えば、これが主題です。これについては別のところで詳しく話したりしたいのですが、自分の中でのライブラリの理想として、「やがて消えてなくなるライブラリ」というものがあります。これは、不要になったら淡雪のように溶けてなくなるようなライブラリが理想ということです。最近のOSS界隈で有名なソフトウェアを見てみると個人で作ったものが市民権を得ると言うよりは、何らかのメンテナンスを行う母体がある所のOSSが市民権を得ているような気がします。ドキュメンテーションとメンテナンスに関してはけっこう多大なりソースが必要そうで、それを個人で賄っている人たちもいますが(尊敬しています)どこか辛そうな印象も受けたりしています。加えて、何らかの概念や世界観を元に作るようなある種opinionatedなソフトウェアは、ドキュメントを手厚くする必要があったり、チュートリアルのための動画を作ったり、コミュニケーションのための場を設けたり、コントリビューションのガイドラインを設けたり、広報活動的なことが必須になっていっている気がします。ある種のアイドル活動のような振る舞いを迫られるというようなイメージです。やりたいのはコードを書くことなのでそちらにはあまり個人のリソースを割きたくありません(個人的には)。標準(他の人々がメンテナンスをしてくれるであろう環境)からは外れず、やがて来るであろう公式の未来だけを信じて先に利用しつつ、不要になったら取り外すというのが良い生活習慣なのではないか?というような認識の人も多くなっているような気がします。polyfillを使うということです。政治的な手腕を発揮したい人々(?)など、標準として提案しつつ、これは標準だという体でガンガン依存していくみたいな活動(prolyfil)を行う人も居ましたが、個人的にはそこまで主張することが好きというわけではないので逆の立場を選びました。自分の作ったものが標準(主流)というわけではなく、自分の作ったものは脇道(支流)であるということを前提にすることにしたのです。必要なときには、必要なときだけ、自分が作ったライブラリをしれっと使い便利に過ごし、標準が追いついてきたら(あるいは不要になったら)、またしれっと溶けてなくなったかのように消してしまうという振る舞いが理想なのではないかと思うようになりました。これが「やがて消えてなくなるライブラリ」です。この「やがて消えてなくなる」というテーマは、ずっと心の中にあったのですが、たまたま、create-react-appなどを試してみたりする中で、--exposeというオプションを設けていることに気づきました(例えば、create-react-appは--exposeを実行するとwebpackを使ったbuildに変換される)。どのように取り外すかという部分の体験についてこの--exposeというオプションを使うというのはありかもしれないと思い試しに自分でも作ってみるかと思ったのがそもそもライブラリを更新した始まりでした(ただし、create-react-appのexposeはけっこうメンテナンスが大変そうな印象がある(中をまじめに覗いてはいない))。作業としては、いきなりコードを書き換えるのではなく、アイデアレベルでスケッチのような形でgistに幾つかコードを書いてみていけそうかどうか試してみたりしていました。https://gist.github.com/podhmo/0cc69b8c1114260ca8ccb72e3892e0e4https://gist.github.com/podhmo/ef969b6624c945746b59af01601c57daそして、これはけっこう手軽にできそうということになり、書き換えに至ったという形です。--expose全てのhandofcatsでコマンド化した関数は、--exposeというオプションを持っています。冒頭のコードにおいても、--exposeというオプションをつけることで、標準ライブラリ以外に依存していない形式のコードが出力されます。みたいなオプションがあっても良いのかもしれません)。対応は個人的にも常用したくなるような嬉しいことがあります。個人的な話かもしれませんが。個人的にはけっこう頻繁にgistを使っています(先程挙げたスケッチレベルと言ったコードもそうでした)。そのgistを共有する時に依存を外したいということはたびたびあります。バグの再現手順の作成であっても、基本的には最小のサブセットを目指すことが多いと思います。そのようなところでの試行錯誤の最中では一時的にこのhandofcats(今回書き換えたライブラリのこと)を使い、後に共有のためにargparseの実装に書き換えるということをやっていました。この不毛な作業から開放されるのはけっこう嬉しさがあります。気が乗らないときにはどうせ書き直すのだからとはじめからargparseを使った実装にしていました。それがこれからは気にする必要がなくなるのでとても良い感じです。serverが欲しくなることが...2017-08-05argparseでsubcommandを作るためのユーティリティサブコマンドを作る時に何らかのライブラリに依存して良いならc...2017-02-11最近pythonでcliのコマンドを作る時にやっていること最近cliのコマンドを作る時にやっていることをまとめてみる。componentという機能を追加した月別アーカイブはてなブログをはじめよう!podhmoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。