dict遊びポエムです。はじめに絵を描くことが好きだった人が絵を描く仕事につく。絵を描くことを仕事にしている人がたまたま余暇にらくがきの絵を描く。仕事でも絵を描いているのだからもう描かなくても良いじゃないかという声もかけられるが、余暇の落書きは仕事としての絵とは何だか違うような気がして、やっぱり余暇にらくがきをする。みたいなことがプログラミングにもあるのではないかということを最近良く思う。これは個人的な話でありすごく主観的な捉え方によるものだけれど。絵を描くという領域における余暇の落書きに類するような行為をコードを書くという領域上で行っているような気がした。思い返してみると息抜きとしてのプログラミングというものが自分自身の中には存在している気がする。それは面白そうなアプリケーションやライブラリを探すなどのいわゆる情報収集とも違うものではあるし、何か作りたいアプリケーションが存在していてそのアプリケーションを開発するというのとも違う気がする。コードを書くことで自分の中にあるストレスが消えていくような、いわゆる息抜きとしての行為のプログラミングがどういうものかということを、とりとめもなく書いてみることにした。すべての人がやっているわけではないし。万人に当てはまるようなものではないけれど。コードを書くときの楽しさコードを書くいった時に思いつくものは以下の様なものだった。何らかの領域上に何らかの日常的な動作・処理が存在していて、それを機械に実行可能な形に翻訳すること何らかの動作が存在していてそれをなぞるような形で振る舞いを記述するということがある種のデッサンに似たような感じを受ける。そのような何らかの振る舞いの記述をコーディングと呼んでいるような気がする。場合、コーディングと言った場合にスキルという言葉もセットになってついてくる事が多いが、今回はそのスキルに関しては全く触れるつもりはないし。スキルを向上するためにどうすれば良いかみたいな話はしない。趣味という意味でコードを書くということをしている事があるようなきがする。そのコードを書く楽しさとはなんだろうかみたいなことを例をあげてどうにか文章という形で表現してみたい。dict遊びpythonのdictpythonにはdictという組み込みの型が存在する。このdictは他の言語では連想配列と呼ばれたりマップと呼ばれたりすることもあるかもしれない。apiのレスポンスがJSONの形式で返されるような時に、そのレスポンスをpython上に持ってきたときにはdictの型の値にデコードされてきたりする。"b"基本的にはkeyとvalueのpairになっていて、渡したkeyに対応するvalueが存在する場合にそれが結果として返ってくる。上の例ではdictのkeyのvalueも文字列だけれどもちろんvalueをdictにしたdictを作ることもできる。そのdictのvalueもまたdictになって...というように再帰的にdictを持ったdictはツリー状の構造になる。apiのレスポンスもそのようなツリー構造のデータが返ってくる事が多い。20dictへのアクセス任意の深さへのアクセスどこに何が入っているか完全にわかっている場合にはただただkeyとして渡していけば良い。言え深さが異なる位置にアクセスしたくなる事があるかもしれない。と3回のアクセスが必要かもしれない。この特定の値を取得するために必要なkeyの列をpathと呼ぶことにする。pathの長さは不定で、あるものは2かもしれないし。あるものは5などかもしれない。そのようなパスを受け取って望みの値を取るような処理は書けるかというとたぶん以下の様になる。d["a"]["b"]任意回のアクセスこのような関数が書けると何が嬉しいかというと、値の位置さえわかっていれば、値の深さによらず望みの値を一気に取得する処理を書くことができるようになる。コストの様な数を取り出してその合計を計算してみる。total今度は、深さが不定なツリーから値を1つ取れるだけでなく、ツリー状のdictから好きな個数の値(上の例ではコスト)を一気に取得する事ができた。ここでちょっと考えてsumという関数があるから使えば短くなると考えて以下のように書くかもしれない。path_list)こういう風に同じ処理を短くあるいはより手軽に書けないかと考えるが楽しいというときもあるかもしれない。上手く短く書けたときには頭の中が整理されたような気がする。誤ったpathを含んだリスト先程の例では全ての欲しい値の位置が分かっている状態について考えていた。実際には値の位置が分かっていない事が多いかもしれない。いうpathには値が存在していないかもしれない。いう場合にも適切に合計を計算したい。言え存在しないpathを指定してしまった場合の対応をすることはそんなに難しくない。accessの部分を存在しなかった場合には何にも影響を与えない値を返すようにして使える特別版に置き換えれば良い。以下の様な関数を作る。dこの関数をaccessの代わりに使えば誤ったpathを含んだリストを受け取ったとしても正しい合計値を返す事ができる。path_list)不完全なpathでのアクセス誤ったpathを含んだリストだけではなく、そのpathが不完全であるかもしれない。終わる値を取りたいということかもしれない。これはちょっと頭を捻る必要がある。いうような形かもしれない。このような末尾と途中の一部だけが分かるpathから値を取得する関数を考えてみる。30]再帰がでてきたが全部取得する事ができた。頑張りすぎないように探索する深さを制限しても良いし。条件に合致したらすぐに1つだけ返すように変えてみても良い。毎回探索するのも馬鹿馬鹿しいのでたどり着いた値を浅い場所に保持するようにしてみよう。上の例のdictを渡すと以下のようになる操作を考えてみる。中だけ観れば良いようになった。同じkeyのものがあったら衝突してしまうから実はリストにしたほうが良いなどもあるかもしれない。この変更の操作を記述するにはどうしたら良いんだろう。関数の引数に関数を渡すこともできる。以前に定義した不完全なpathでのアクセスを行う関数に関数を渡せるように改造することを考えてみる。modify)上手くいっていそう。}実行した結果x,zの値が$costに移動している。"$cost/z"のことなどを指している)。本当に?すこしだけ考えてみると途中の意味を良く決めていない状態のままコードを書いていた。まとめられる対象に含まれて欲しいかもしれない。100},}少しコードを変えてみる。'$cost/y'}}}dequeの利用が二重になっている部分が気に入らないところではあるけれど。一応作りたかった答えを作る事はできている。条件に合致した時、その位置の物を直接返すようにする場合もしかしたらの話、たとえば先程の処理を以下のような形で書けるとしたらどうだろう。"$cost/{}".format(top_key)今度は欲しい値がこちらに直接やってくるので関数を受け渡す必要がない。このように書ければもう少し先程の処理なども気軽に掛けたのかもしれない。最後の値だけではなく途中の値も全て欲しい場合あるいは最後の値だけではなく途中の値も全て欲しい場合もあるかもしれない。階層でも何か副次的な処理が行いたい場合もあるかもしれない。以下の様になってほしい。],}今度は$costの他に$ysも現れてそのyの階層以下の値を別途$ysに持ちたい。先程のwalkを何度も使えばできるが酷い形になる。on_y)同じ名前の位置に対して同じ処理を行いたいさらに酷い形を進めてみよう。a,b,a,b,a,b,a,b,a,bと続いていく木に対してaのときにだけ何らかの処理を付け加えたい場合にはどうすれば良いだろう?これももちろんアクセス用の関数を何度も書けばこなすことができる。on_a0)しかしこれは馬鹿馬鹿しい。ところで自分自身を返す事はできないのだろうか?例えば操作関数がもう1つ引数を取り、引数自体が自分自身を返すみたいな構造。それができるなら以下の様に書けるはず。on_a0)あるいはpathの探索をその階層のkeyの一致のみで調べていたが。expected)加えてある程度、変更用の関数の引数の形式も自由にできる。以下のようなPathContextを定義すると、その時点まで辿った状態を(パンくずリストの様な履歴)を受け取る事ができるようになる。value)というようなことをしていた。いうちょっとしたコンパクトな処理に対する何らかのアイデアから端を発して不満を解決しつつ、より広い領域に対しても、意図していた通りの振る舞いさせる記述ができないか考えながら変更を加えるみたいな作業が気晴らしになっているらしい。componentという機能を追加した月別アーカイブはてなブログをはじめよう!podhmoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。