Shizuoka.py #4 pythonで設定ファイルを使う 質疑と資料について追記版
-
Upload
sano-hiroshi -
Category
Engineering
-
view
281 -
download
4
Transcript of Shizuoka.py #4 pythonで設定ファイルを使う 質疑と資料について追記版
自己紹介
● hiroshi sano hr-sano.net / @hrs_sano645
● 会場の地域に住んでます(出身)
● 普段は実家の設計事務所でIT周りの便利屋
○ たまにishiilab.netにお手伝い
● 最近プログラミングしてない(汗)リハビリ中
2
実体験/主観で語ります
(個人談なので異論などあればお願いします)
4
環境設定ファイルとは
環境設定ファイルとは - IT用語辞典 Weblio辞書
アプリの挙動に関する項目を保持するために使います
環境設定ファイルとは、パソコンをユーザー自身にとってより使いやすくするために行われた環境設定の情報を収めたファイルのことである。マウスを移動するスピードやディスプレイの表示解像度などのハードウエア設定や、アプリケーションソフトの画面表示や動作に関するものなど、多岐にわたる項目が保存されている。
5
もくじ
1. いつ設定ファイルを使う?
2. どの設定ファイルを使う?
○ ini, json, yaml
○ ipython notebookでハンズオン
6
もくじ
1. いつ設定ファイルを使う?
2. どの設定ファイルを使う?
○ ini, json, yaml
○ ipython notebookでハンズオン
7
いつ設定ファイルを使う?
8
いつ設定ファイルを使う?
9
いつやるか、
_人人人人人人人人_
> 今で..... < ̄Y^Y^Y^Y^Y^Y^Y ̄
それ去年の・・・
「ダメよ〜、ダメダメ!」
10
いつ設定ファイルを使う?
11
● 必要になるタイミング
○ アプリの成長過程
○ 扱う処理の複雑さ
● 必要になるアプリの形態
○ 単純な数行のスクリプトには必要ないが、
IDEとかには必要
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
12
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
この辺で必要になった
13
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
14
1.単純なスクリプト(プロトタイプ)
単純に処理をまとめて、動くようになった程度
● スクリプト内に設定を書く
○ コード本体に入れてもまだ気にならない?
● スクリプトの上に共通で使う変数を用意すれば
困らない
15
main
1.単純なスクリプト(プロトタイプ)
16
Input OutputProcess
例:ファイル開いて処理してファイルとして書き出す
main
1.単純なスクリプト(プロトタイプ)
17
Input OutputProcess
例:ファイル開いて処理してファイルとして書き出す
● 入力ファイル名 ● 処理のパラメータ ● 出力ファイル名
● スクリプト内で変数定義● コマンドの引数で指定
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
18
2.モジュールが複数作られる
それぞれの工程をモジュールとして分ける
● 工程の操作はmain的な場所で行う
○ mainのスクリプト上で変数宣言して使う
● モジュールの呼び出す関数やクラスにパラメータを
入れれるようにする
19
main
2.モジュールが複数作られる
20
関数/クラス の引数
Input
例:ファイル開いて処理してファイルとして書き出す
OutputProcess
● 入力ファイル名 ● 処理のパラメータ ● 出力ファイル名
2.モジュールが複数作られる
● モジュールを設定ファイル的に扱う
スクリプトファイルも設定ファイルとして使われる
(Vagrantの設定ファイル(Vagrantfile)はRubyですよね)
21
main
2.モジュールが複数作られる
22
config value:module
Input
例:ファイル開いて処理してファイルとして書き出す
OutputProcess
● 入力ファイル名 ● 処理のパラメータ ● 出力ファイル名
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
23
3.複雑になる
● ファイルの処理する種類が増える
○ パラメータが増える
○ 組み合わせも増える
24
3.複雑になる
25
Input2
例:ファイル開いて処理してファイルとして書き出す
Output2Process2
Input1 Process1 Output1
Input3 Process3 Output3
3.複雑になる
26
Input2
例:ファイル開いて処理してファイルとして書き出す
Output2Process2
Input1 Process1 Output1
Input3 Process3 Output3
● 入力ファイル名 ● パラメータセット1● パラメータセット2● パラメータセット3● …..
● 出力ファイル名
3.複雑になる
27
Input2
例:ファイル開いて処理してファイルとして書き出す
Output2Process2
Input1 Process1 Output1
Input3 Process3 Output3
● 入力ファイル名 ● パラメータセット1● パラメータセット2● パラメータセット3● …..
● 出力ファイル名
一連の処理の組み合わせがたくさんになる
(書くのが面倒になった)
3.複雑になる
● 組み合わせごとの設定をそれぞれまとめる
○ 変数も駆使して
○ 辞書にぶっこむ(辞書の辞書も出来ますし)
● まだPythonスクリプトでも行ける
○ 便利に使えるなら
28
アプリが成長する過程
1. 単純なスクリプト(プロトタイプ)
2. モジュールが複数作られる
3. コード量が増えて複雑になる
4. フリージング/GUI?/パッケージ化?
29
4.フリージング/GUI?/パッケージ化?
30
Inputs
例:ファイル開いて処理してファイルとして書き出す
OutputsProcesses
GUI Wrapper
4.フリージング/GUI/パッケージ化?
31
Inputs
例:ファイル開いて処理してファイルとして書き出す
OutputsProcesses
GUI config
Previousconfig
Process configs….
4.フリージング/GUI?/パッケージ化?
● 扱う情報量が多い / 可変する設定も増えてくる
○ =管理しやすくしたくなる
● スクリプトで設定をまとめるもまだ大丈夫
● フリージングした場合はスクリプトを読み込む方法
の提供が必要
○ 結構面倒。。。
32
4.フリージング/GUI?/パッケージ化?
33
さすがに
_人人人人人人人人_
> 今でしょう! <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
[まとめ]いつ設定ファイルを使う?
34
● 必要になるタイミング
○ アプリの成長過程
○ 扱う処理の複雑さ
● 必要になるアプリの形態
○ 単純な数行のスクリプトには必要ないが、
IDEとかには必要
もくじ
1. いつ設定ファイルを使うか?
2. どの設定ファイルを使う?
○ ini, json, yaml
○ ipython notebookでハンズオン
35
Pythonで扱えそうな設定ファイル
人が読みやすくて描きやすい物を選ぶと(この辺も主観)
1. INI
2. json(?)
3. yaml
36
Pythonで扱えそうな設定ファイル
人が読みやすくて描きやすい物を選ぶと
1. INI => ConfigPerser(標準ライブラリ)
2. json => json(標準ライブラリ)
3. yaml => PyYaml(pip install pyyaml)
37
INIファイル
● 様々な場所でよく見るファイル
● セクション>オプション名とバリューで設定を定義
○ ConfigPerserの場合
38
INIのメリット/デメリット
メリット
● 一般的に良く使われてる
● 文法はシンプル
● コメント書ける
デメリット
● 複雑なデータは向かない
● 拡張フォーマットの存在
39
JSON(JavaScript Object Notation)
● WEB系のAPIなどでお馴染み
● javascriptのオブジェクトリテラルそのまま
○ Pythonの辞書的な扱いができる
40
jsonのメリット/デメリット
メリット
● よく使われてきてる
● 汎用性高い
● データの表現が多い
デメリット
● コメントが書けない
● 13日の金曜日の映画と間
違える
41
YAML(YAML Ain't Markup Language)
● jsonと同じような、データ交換フォーマット
● バージョンが1.0, 1.1, 1.2(beta?)がある。
● Pythonでは1.1 = PyYAML
○ 1.1のリファレンス実装らしい
42
YAMLのメリット/デメリット
メリット
● 1.1に準拠するならpython
では使いやすい
● 豊富なデータ表現
● コメント書ける
43
デメリット
● 他の環境のバージョンの
違いで流用難しい
オルタナティブ(既存の改善)
● ini(ConfigPerser) -> Configobj ()
○ ini構文の拡張
○ matplotlib, ipythonでも採用
● JSON -> Relaxed JSON ( rson)
○ jsonの文法縛りがゆるい
○ コメント書けるらしい
44
設定ファイルって結構フリーダム!
使いやすいか、実績があるかで選びましょう
45
設定ファイルって結構フリーダム!
フリーダムすぎるのは「妖怪の仕業」
どうにかしてほしいよね・・・
46
個人的にはYAML使います
その宣言いらなくね?
47
まとめ
1. いつ設定ファイルを使うか?
2. どの設定ファイルを使う?
○ ini, json, yaml
○ ipython notebookでハンズオン
48それでは「ごきげんよう」
おまけ
時間が余ったら紹介
49
Github中の人提案の「TOML」
● https://github.com/toml-lang/toml#example
● 見た目はiniの独自拡張っぽい
○ 結構書きやすそう
● Pythonのパーサー
https://pypi.python.org/pypi/toml/0.8.2
50
Winのレジストリ
● Pythonの標準ライブラリにあります
○ _winreg(2系), winreg(3系)
● Windowsオンリーです(よね?)
51
apacheのhttp.confで使うようなあれ
● http://stackoverflow.com/questions/237209/any-python-
libs-for-parsing-apache-config-files
(丸投げサーセン)
● 汎用かつ一般的な方法はなし?
52
XMLは
すみません。扱ったことありません。。。
ElementTreeとかlxmlとかですかね
53
linuxのconf.d
● 特定のモジュールを使うような話はなし?
● ディレクトリ>該当する設定ファイルを探すだけ
○ glob.globとワイルドカード指定
○ os.listdir + 正規表現で絞る
(想像なので実際にやるとハマるかもしれません、
設定ファイルの文法チェックとか)
54
55
発表終了後の追記
30分発表の予定が1時間ですみませんでした(懺悔)
56
今日利用した資料
githubにあります
https://github.com/hrsano645/shizuokapy-no4-handson
57
質疑
● jsonとyamlは何方が最初に出てきた?(@fmkz___)
58
質疑:jsonとyaml、出が早いのは何方?
yaml
http://yaml.org/spec/1.0/ のリリース日とすると
Final Draft 2004-JAN-29 とあり、
Copyright © 2001-2004 Oren Ben-Kiki, Clark Evans,
Brian Ingerson
ともあるので、2001年ごろから策定が始まったようです
59
質疑:jsonとyaml、出が早いのは何方?
yaml
http://yaml.org/spec/1.0/ のリリース日とすると
Final Draft 2004-JAN-29 とあり、
Copyright © 2001-2004 Oren Ben-Kiki, Clark Evans,
Brian Ingerson
ともあるので、2001年ごろから策定が始まったようです
60
質疑:jsonとyaml、出が早いのは何方?
json
http://www.json.org/json-ja.html の引用
RFC4627で正式となったのが、July 2006でした。
61
JavaScriptプログラミング言語 (ECMA-262標準第3版 1999年12月)の一部をベースに作られています。
質疑:jsonとyaml、出が早いのは何方?
そのため、
● 考えとしてはjsonが早くて
● 仕様としてリリースされたのは yamlが早い
と思います。
62