やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

Pythonドキュメントの見出しからディレクトリ構造を作った

形だけ。

成果物

GitHubpylangstudy.HeadingToDirectory.201705160717

前回まで

Pythonでパスが扱いにくい

  • 実行ファイルパスの取得が冗長かつ暗号的 os.path.abspath(os.path.dirname(__file__))
  • パス結合APIのために結局文字列操作を要する。APIの存在意義…
コード 説明
os.path.dirname(path) ファイル名以前のディレクトリすべて取得する。
os.path.basename(path) ファイル名と拡張子のみ取得する。
os.path.splitext(path) 拡張子のみ取得する。

メモ

https://docs.python.jp/3/contents.html から見出しの木構造を取り出してディレクトリ構造にする。

  • /whatsnews/3.6.hmlt3.6ディレクトリにする
    • 葉ノードでない場合で.htmlファイルにリンクがある場合、そのファイル名をディレクトリにする。
    • リンクが見出し(https://docs.python.jp/3/whatsnew/3.6.html#pep-498-formatted-string-literals)#pep-498-formatted-string-literalsの場合、見出しをディレクトリにする

課題

見出しディレクトリ配下をどのような構成にするか。

  • 見出しディレクトリの配下には1つ以上の課題が入る
    • 課題はどんな形にするか
      • /見出し/index.html, /見出し/課題1.html
      • /見出し/課題1/article.html
    • 課題で生じた疑問についてはどんな構造にするか
      • /見出し/課題/question_index.html, /見出し/課題/疑問1/index.html
      • /見出し/.questions/疑問1.html

課題はPythonドキュメントの細分化なので木構造にできるかもしれない。部分集合として綺麗に分けることができるかもしれない。

しかし、疑問については木構造化が難しいと思われる。事前に全体像がわかっているなら可能だが、それなら疑問自体生じない。わからない上でインデックス化するなら時系列リストが妥当か。

ディレクトリ数の見積

以前の集計では葉ノード数は2938件だった。節ノード数をあわせるともっと多いはず。ファイラによると3622個件のアイテムがあるらしい。

学習する見出しが2938件、グループは684件(= 3622 - 2938)。見出しから1コードに落とし込める単位として「課題」にする予定。すべての見出しに対して課題を作ると2938件以上になる。

f:id:ytyaru:20170516113843p:plainf:id:ytyaru:20170516113847p:plain

所感

さすがに手動では多すぎるのでできてよかった。ざっくり規模を定量化してみたが多すぎて無謀。自動化、優先順位、絞り込みが必要か。