歩いたら休め

なんでこんな模様をしているのですか?

【Python】抽象基底クラス(abc)のメリット

Pythonはドキュメントが整備された言語ですが、専門的な用語も多く「結局この機能をどう使えば良いんだ」と思ってしまうことがあります。

この間同僚と abc モジュールの話になり、「結局何のメリットがあんのや」という話になりました。私は abc.ABC を使うことが多いのですが、改めて考えるとメリットを説明できなかったので調べてみます。

docs.python.org

このモジュールは Python に PEP 3119 で概要が示された 抽象基底クラス (ABC) を定義する基盤を提供します。なぜこれが Python に付け加えられたかについてはその PEP を参照してください。 (ABC に基づいた数の型階層を扱った PEP 3141 と numbers モジュールも参照してください。)

そして抽象基底クラスの説明はこちらです。これはきつい😅

(抽象基底クラス) 抽象基底クラスは duck-typing を補完するもので、 hasattr() などの別のテクニックでは不恰好であったり微妙に誤る (例えば magic methods の場合) 場合にインタフェースを定義する方法を提供します。ABC は仮想 (virtual) サブクラスを導入します。これは親クラスから継承しませんが、それでも isinstance() や issubclass() に認識されます; abc モジュールのドキュメントを参照してください。Python には、多くの組み込み ABC が同梱されています。その対象は、(collections.abc モジュールで) データ構造、(numbers モジュールで) 数、(io モジュールで) ストリーム、(importlib.abc モジュールで) インポートファインダ及びローダーです。 abc モジュールを利用して独自の ABC を作成できます。

abcの提案理由

上の例にあるPEP3119を追ってみます。翻訳を引用していきますが、必要に応じて原文も当たります。

www.python.org

mft.la.coocan.jp

一方で、古典的 OOP 理論家による覗き込み批判の一つは形式化の欠如であり、 何が覗き込まれるかについての場当たり的な性質です。 Python のような言語、つまりオブジェクトのほとんど全ての部分を外部コードが覗き込み、直接アクセスできるような言語においては、オブジェクトが特定のプロトコルに適合しているかどうかを調べるいくつもの異なった方法があります。 たとえば「このオブジェクトは変更可能なシーケンスのコンテナですか?」 という問には、’list’ が基底クラスにあるかどうか探す、’__getitem__’ という名のメソッドを探すといった解答方法が思いつきます。 しかし間違えてはいけないのは、これらのテストが当たり前に見えるとしても、 どちらも正しくないということです。 一方は間違って否定することがあり、もう一方は間違って肯定することがあります。

「呼び出し」は「オブジェクトにメソッド呼び出しを通して働きかけること」で「覗き込み」は「外部のコード(オブジェクトのメソッド以外のもの)が、型やオブジェクトのプロパティを調べたり、その情報に基づいてそのオブジェクトをどのように扱うか決める」ことだと説明されています。原文には'invocation' and 'inspection'とあります。

一方で、古典的 OOP 理論家による覗き込み批判の一つは形式化の欠如であり、 何が覗き込まれるかについての場当たり的な性質です。 Python のような言語、つまりオブジェクトのほとんど全ての部分を外部コードが覗き込み、直接アクセスできるような言語においては、オブジェクトが特定のプロトコルに適合しているかどうかを調べるいくつもの異なった方法があります。 たとえば「このオブジェクトは変更可能なシーケンスのコンテナですか?」 という問には、’list’ が基底クラスにあるかどうか探す、’__getitem__’ という名のメソッドを探すといった解答方法が思いつきます。 しかし間違えてはいけないのは、これらのテストが当たり前に見えるとしても、 どちらも正しくないということです。 一方は間違って否定することがあり、もう一方は間違って肯定することがあります。

abc導入の目的は、「そのオブジェクトに特定のメソッドが存在することを保証すること」のようです。

この PEP はこうしたテストの組織化戦略、抽象基底クラス (Abstract Base Class, ABC) として知られるものを提案します。 抽象基底クラスは単純な Python クラスでオブジェクトの継承ツリーに加えられ、 外部からの覗き込みに対してそのオブジェクトの特定の特性を伝えるものです。 テスト自体は isinstance() を使って行われ、 特定の ABC の存在はそれの定めるテストを通ったことを意味します。

それに加えて、ABC はある型の特徴的な振る舞いを確立する最小メソッド集合を定義します。 ABC に基づいてオブジェクトを判別するコードは、 それらのメソッドの存在を信じることができます。 これらのメソッドのそれぞれは一般化された抽象的な意味の定義を ABC の文書中に見つけることができます。 これら標準的な意味定義は強制力はありませんが、 従うことが強く推奨されます。

具体的な機能

仕様は概要で列挙されたカテゴリーの順番に従います:

  • isinstance() および issubclass() の多重定義(オーバーロード)方法。
  • “ABC フレームワーク” として使う abc 新モジュール。 このモジュールでは ABC と共に使うメタクラスと抽象メソッドを定義するのに使うデコレータを定義します。
  • コンテナとイテレータに特化した ABC が collections モジュールに追加されます。

3つめは collections.abcの話です。

具体的には「isinstance/issubclassでの判定を正確にすること」「 abstractmethod などのデコレータで、子クラスにメソッドの実装を強制できること」が具体的な機能として挙げられています。

ichitcltk.hustle.ne.jp

後で調べたい点: typingモジュールとの関連

ここは私自身まだ混乱してます。この間の記事でも調べた構造的部分型も、「メソッドが存在することを保証する」ことが目的なのでどういう関連なのか気になっています。typingモジュールでは構造的部分型もサポートされています。

www.slideshare.net

こちらでも「そのオブジェクトに特定のメソッドが存在することを保証すること」は保証できるはずなので、どう使い分けるのか調べてみたいです。

【Python】@classmethodと@staticmethodの使いどころ

今日は @classmethod@staticmethod の使い分け方が話題になりました。私はなんとなく「コンストラクタが複数ある場合は @classmethod を使う」ようにしています。ただ、他の使い道も自分が知らないだけであるんじゃないかと思い、少し調べてみました。

複数の初期化処理を切り分ける(Factory Methodパターン)

こちらの記事にある通りです。

blog.pyq.jp

よく使われる例としては、そのクラスを作るメソッドを書くことです。 以下の例ではクラス Item と、Itemの情報をあるAPIから取得して返す retrieve_from_api というクラスメソッドを実装しています。

class Item:
    def __init__(self, id, name):
        self.id = id
        self.name = name

    @classmethod
    def retrieve_from_api(cls, id):
        res = requests.get(f"https://api.example.com/items/{id}")
        data = res.json()
        return cls(id, data["name"])

www.programiz.com

これはFactory Methodパターンと呼ばれるデザインパターンです。

pydp.info

インスタンス間で共通の変数を保持する

elicon.blog57.fc2.com

やや古い記事なので、Python2系の xrange が使われていて少し懐かしいですね。

class Shape:
    collection = set()
    def __init__(self,x, y):
        self.x = x
        self.y = y

    def update(self):
        self.x += 1
        self.y += 1

    @classmethod
    def add_new_shape(cls, (x, y)):
        shape = Shape(x, y)
        Shape.collection.add(shape)

    @classmethod
    def update_all(cls):
        for shape in Shape.collection:
            shape.update()

def main():
    for p in xrange(10):
        Shape.add_new_shape((p, p))

    q = 0
    while q < 60:
        Shape.update_all()
        q += 1

if __name__ == "__main__":
    main()

(おまけ)@staticmethodの使いどころ

elicon.blog57.fc2.com

また、 @staticmethod は「関数をまとめたクラスオブジェクト(モジュール)を作る場合」に使っています。ただ、Pythonだとファイル単位でモジュールができるので、個人的にはあまり必要性を感じたことがないです。

あとはインスタンス変数やインスタンスメソッドにアクセスしないときにも @staticmethod を使いますが、個人的な経験では、結局後で他のメソッドを呼ぶことになって self を書き足すことが多かったのであまりメリットは感じません。

atsuoishimoto.hatenablog.com

こちらの例は鮮やかですが、なかなかこういう機会はなさそう。

【プログラミング】リスコフの置換原則についてのメモ

会社のコードレビューで、同僚のコードが少しクラス設計が微妙だった(委譲で十分なのに継承でわかりづらくしていた)ことを指摘したことがあります。「こういう場合は委譲ではなく継承を使うべき」という指針として「リスコフの置換原則」や「is-a関係」を説明したかったのですが、

ja.wikipedia.org

T 型のオブジェクト x {\displaystyle x} x に関して真となる属性を q ( x ) {\displaystyle q(x)} q(x) とする。このとき S {\displaystyle S} ST {\displaystyle T} T の派生型であれば、 S {\displaystyle S} S 型のオブジェクト y {\displaystyle y} y について q ( y ) {\displaystyle q(y)} q(y) が真となる。

いろいろな記事を説明してもこんな説明ばかりだったのでうまく説明できませんでした😅

また、いくつかの記事で気になる記述を見つけたので、今後調べる際のためにメモしておきます。「実装の継承」と「インターフェイスの継承(おそらくRustのtraitやHaskellの型クラスのような話だと思いますが)」などもワードも調べてみます。

togetter.com

何か間違ってたらコメントなどください。

「inheritance is not subtyping」問題

tech.nikkeibp.co.jp

 この現象は,is_equal_toのようなバイナリメソッド(自分と同じ型のオブジェクトを引数として受け取るメソッド)が原因で,いわゆる「inheritance is not subtyping」問題として広く知られている(http://portal.acm.org/citation.cfm?id=96721&dl=ACM&coll=portal)。このような問題があるので,「インタフェースの継承は必要だが,実装の継承は有害である」という議論すらあるぐらいだ。

 より正確には,「(実装の)継承とis-a関係を混同してはいけない」というべきだろう。「inheritance is not subtyping」問題からもわかるように,継承したからといって必ずしもis-a関係が成り立つとは限らないからだ。逆に,先のprintableの例からもわかるように,継承しなければis-a関係が成立しない,というわけでもない。

この記事をPythonで読み替えた説明の記事がありました。

uid0130.blogspot.com

実は友人とSlackで会話した時、以下のようなやり取りがあったのですが、実際にOCamlだと構造的部分型の機能でこれをカバーしてるそうです。

彼: 禁止しなくても守れそうだけどな。isEqualToの実装次第じゃない?

私: 親クラスで isEqualTo が実装されていた場合、 子クラス.isEqualTo(親クラス) でオーバーライドして実装するときにややこしそう

彼: isEqualTo の中身次第じゃない? 「あるアトリビュートが同じだったら同じ」というメソッドだったら問題ないと思う。

Python記事からの引用

面白いのは, 継承しなくても, is-aの関係が成立してしまうケースが存在することで, 次のFruitとOarngeクラスの例が考えられます.

厳密な意味(?)でis-a関係が成立しているわけではないですが, equalsによる比較ができてしまい, 一種の部分型(is-a関係)のような振る舞いが可能になります. OCamlなどでは, この辺を型推論により自動的に型付けしてくれるようで, このような型を構造的部分型(structual subtyping)と呼ぶようです(前述のITProの記事より).

少なくとも、「equalsのように自分自身の型の引数をもつメソッドを継承する際、is-a関係(subtypingの関係)が壊れてエラーが出る場合がある」ということは正しそうです。

「実装の継承」と「インタフェースの継承」について

一般に,実装の継承と(is-a関係が成立するという意味での)インタフェースの継承は異なることに気を付けたい。

このあたり、Haskellの型クラスやRustのtrait(他言語の類似機能)と絡めた話が読んでみたいです。

Pythonの世界に落とし込めば、「通常の継承は禁止して、abcモジュールを使ったMixInのみ許可するほうがいい」と主張できそうな気もします。

www.buildinsider.net

【書評】insight(インサイト)を読んで、自己認識おばけから身を守ろう

すごく優秀で論理的な考え方をする人でも、自己認識(自己評価)はとんでもなくて「あいつは俺のこと嫌いだから」とか「あの人は不勉強だから」みたいな雑なレッテルを貼っていて、他の人が客観的に見るとその人のそういう態度に戸惑っているだけということ、私の周りではたまに見かけます。逆に異様に自己評価が低くて他人を羨んでいる割に、「いやお前なんも努力も工夫もしてないじゃん…」って人もいます。

自分自身がそうなってしまう場合もあって、それを気づくことはかなり難しいです。「トイレットペーパーの長い切れ端を靴の裏にくっつけたまま」、自分だけが気づかずに過ごしてしまう場合もあります。

そういう人と付き合って消耗するのも、自分自身がそうなって孤立していくのももううんざり。そういう話をしていたら友達から『insight』という本を教えてもらって、ちょうどいい内容だったので紹介します。

insight(インサイト)――いまの自分を正しく知り、仕事と人生を劇的に変える自己認識の力

insight(インサイト)――いまの自分を正しく知り、仕事と人生を劇的に変える自己認識の力

はじめに

このブログに内容がきれいにまとまっているので読んでください。

www.il-magnifico.com

また、第一章はnoteで無料公開されています。

eijionline.com

『insight』の第1章(後半)を全文公開します。|英治出版オンライン

続きを読む

【書評】『僕らはそれに抵抗できない』を読んで、自分が良い習慣を身につけるヒントにしよう

私のようにスマホで利用するSNSやゲームなどに常習的にハマっている方も多いと思います。ふとしたときにスマホを手にとって、自分の時間が思っていたより浪費されていることを自覚してしまう…。

ただ、現代では完全にテクノロジーを排除することは難しいです。うまい付き合い方を作り上げていく必要があると思って、日々試行錯誤していると思います。

www.diamond.co.jp

友達の間で話題になっていた『僕らはそれに抵抗できない「依存症ビジネス」のつくられかた』がその観点でよくまとまっていて素晴らしい本でした。

内容の概要はこちらのブログがよくまとまっていたので、読んでみてください。私は詳しく紹介することはしません。

note.mu

僕らはそれに抵抗できない 「依存症ビジネス」のつくられかた

僕らはそれに抵抗できない 「依存症ビジネス」のつくられかた

続きを読む

【SageMaker】SageMakerのサンプルをローカル実行してget_execution_role関数がエラーを起こす場合の対処

休みの時間を利用して、こちらのSageMakerのサンプルを試していました。

aws.amazon.com

問題

ただ、ローカルのPC(Mac Book)から利用する場合、下のStackOverflowにある通り、エラーが出て get_execution_role 関数が使えません。

stackoverflow.com

def trained_estimator_from_hyperparams(s3_train_data, hyperparams, output_path, s3_test_data=None):
    # 中略
    knn = sagemaker.estimator.Estimator(containers[boto3.Session().region_name],
        get_execution_role(),
        train_instance_count=1,
        train_instance_type='ml.m5.2xlarge',
        output_path=output_path,
        sagemaker_session=sagemaker.Session())
    knn.set_hyperparameters(**hyperparams)
    # 後略

そもそも、ドキュメントには次のように書かれています。

次の Python コードをコピーして、ノートブックの最初のセルに貼り付けます。「Amazon SageMaker をセットアップします」で作成した S3 バケットの名前を追加し、コードを実行します。get_execution_role 関数は、ノートブックインスタンスの作成時に作成した IAM ロールを取得します。

SageMakerの利用し始めには多少混乱すると思いますが、「ノートブックインスタンス」と「トレーニンインスタンス」が別に存在して、 get_execution_role は「ノートブックインスタンスから自分のroleを取得する」ための関数です。

対処

aws.amazon.com

「オンプレミス環境から Amazon SageMaker を利用する」の記事にもある通り、単純に自前で文字列で指定すればいいだけです。

ひとまず私は、SageMakerとS3(モデルやデータの読み込みに必要)を読み込むロールを付けて直接文字列で指定しました。

def trained_estimator_from_hyperparams(s3_train_data, hyperparams, output_path, s3_test_data=None):
    # 中略
    knn = sagemaker.estimator.Estimator(containers[boto3.Session().region_name],
        "arn:aws:iam::***********:role/sagemaker-execution",
        train_instance_count=1,
        train_instance_type='ml.m5.2xlarge',
        output_path=output_path,
        sagemaker_session=sagemaker.Session())
    knn.set_hyperparameters(**hyperparams)
    # 後略

【本】『地域再生の失敗学』を読みました

度々見かけるので読んでみました。

地域再生の失敗学 (光文社新書)

地域再生の失敗学 (光文社新書)

話の内容としては、こちらのブログを読んでみてください。

blog.goo.ne.jp

野中郁次郎さんに触れている箇所

いわゆる『地方創生』の文脈以外ですが、野中郁次郎さんの話が度々出てきます。『失敗の本質』や『知識創造企業』などの本の著者です。

www.slideshare.net

第三章では、「シリコンバレーではカフェで起業家同士が相互作用する仕組みができていて、地方でもそれと似た仕組みを作る必要がある」という趣旨で触れられています。

これはたとえば、「リソース・ベースト・ビュー」という理論で説明できます。これは「企業や人が競争優位に立つには、価値があり、希少で、模倣が必要な資源をもっていないといけない」という考え方です。これからのビジネスでもっとも重要な資源は、いうまでもなく知識と情報です。『失敗の本質』でも広く知られる一橋大学名誉教授の野中郁次郎先生は、知識には「形式知」と、言語化できない「暗黙知」があり、この二つの知を相互作用させることがこれからの経営資源になるとおっしゃてています。すなわち、そのような顔を合わせることでしかつかめない「雰囲気」などに含まれる情報・暗黙知が重視されるのです。

第四章でも触れられています。

飯田 政策立案において次善策やコンティンジェンシープラン(不測の事態でのリスクを最小限に抑えた計画)の検討は必要不可欠なはずです。しかし、日本では「成功したらAを、失敗したらBを、想定外の事態の場合は……」と枝分かれになったプランをつくると、あまりいい顔をされませんよね。旧日本軍の作戦面での愚かさを描いた『失敗の本質』の共著者である野中郁次郎氏が経営学者であったことは、非常に示唆的です。軍隊も日本の組織も「日本的な思考」という点でlk腰痛していることを示していると思います。

「そんな弱腰でどうするんだ!」と。

世界はフラット化しなかった

第三章の早稲田大学の入山章栄教授の講義も面白く感じました。

www.waseda.jp

しかし、ほんの一〇年前はまるで逆の主張が流行していたことを覚えていらっしゃる方も少なくないでしょう。その典型例が、トーマス・フリードマンというジャーナリストが書いた『フラット化する世界』(日本経済新聞社、二〇〇五年。原著は二〇〇五年刊行)です。インターネットの普及や、後進国とみなされていた国々の急速な経済発展により、世界中にモノ、ヒト、カネ、情報がまんべんなく行き渡るようになり、世界は均等化していくというのがこの本の主張で、大変なベストセラーになりました。

フラット化とは全く逆の主張をしているのが、都市経済学者のリチャード・フロリダです。彼は脱工業化したアメリカの都市においては労働者の三割もあたる「クリエイティブ・クラス」がイノベーションを生み出し、クリエイティブ・クラスが集積する都市とそうでない都市で明暗が分かれると主張しています。フロリダの議論については、当初実証性に乏しいという批判が中心でしたが、近年の実感、そしてファクトとしても実際にそうなりつつあるというのは多くの都市経済学者・経営学者の同意するところではないかと思います。

フラット化する世界 [増補改訂版] (上)

フラット化する世界 [増補改訂版] (上)

クリエイティブ都市論―創造性は居心地のよい場所を求める

クリエイティブ都市論―創造性は居心地のよい場所を求める

www.mec.co.jp

それに対して、先のリチャード・フロリダ教授は、「世界中の経済活動、特に知的活動や起業活動などは、特定の都市など狭い地域への集中が進んでいる。 すなわち世界はむしろ『スパイキー化』(ギザギザしている、という意味)しつつある」と主張しています。

私もこの意見に賛成ですし、多くの経営学者や経済地理学者も賛成なのではないでしょうか。そして、私はさらにこの傾向が加速すると思っています。なぜなら、インターネットで確かに情報は普及するのですが、逆に言えば、そのような情報は誰でも手に入れられるので、「価値がなくなる」からです。

その他

あといろいろメモ。

fujipon.hatenadiary.com

togetter.com

akiya123.hatenablog.com