形だけ。
成果物
pylangstudy.HeadingToDirectory.201705160717
前回まで
- http://ytyaru.hatenablog.com/entry/2018/03/09/000000
- http://ytyaru.hatenablog.com/entry/2018/03/10/000000
- http://ytyaru.hatenablog.com/entry/2018/03/11/000000
- http://ytyaru.hatenablog.com/entry/2018/03/12/000000
Pythonでパスが扱いにくい
- 実行ファイルパスの取得が冗長かつ暗号的
os.path.abspath(os.path.dirname(__file__))
- パス結合APIのために結局文字列操作を要する。APIの存在意義…
- http://qiita.com/FGtatsuro/items/1ab9ebf6505bef1834f8
- こういう細かいパス文字列の違いをうまいことやってくれるからパスAPIを使うと思うのだが…
コード | 説明 |
---|---|
os.path.dirname(path) |
ファイル名以前のディレクトリすべて取得する。 |
os.path.basename(path) |
ファイル名と拡張子のみ取得する。 |
os.path.splitext(path) |
拡張子のみ取得する。 |
メモ
https://docs.python.jp/3/contents.html から見出しの木構造を取り出してディレクトリ構造にする。
/whatsnews/3.6.hmlt
の3.6
もディレクトリにする
課題
見出しディレクトリ配下をどのような構成にするか。
- 見出しディレクトリの配下には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件以上になる。
所感
さすがに手動では多すぎるのでできてよかった。ざっくり規模を定量化してみたが多すぎて無謀。自動化、優先順位、絞り込みが必要か。