計算で使わなくて条件分岐で使う変数について

Question

pythonに限った話ではないんですけど、計算で使わなくて、条件分岐の条件として使う変数の中身って、文字列の方がわかりやすくて良かったりしますか？個人的な偏見なんですけど、文字列型って重そうなイメージがあるから、必要がなかったら使わないようにしていたんですけどどうなんですかね？

image_mode="標準"

#何らかのイベントが起きたら（ボタンが押されたとか）
if event==True:
    image_mode="グレースケール"

if image_mode=="グレースケール"
    #何らかの処理

Answer 1

ことパフォーマンスに関してなら、「こうだと思う」とか「他の言語ではこうだ」なんていう話はただの害悪です。
「推測するな、計測せよ」という(誰が言ったか分からない)格言や、「計測すべし。計測するまでは速度のための調整をしてはならない」という哲学の通りです。

# (1) int
a1 = 1
b1 = 2

# (2)1文字目で違うことがわかる長さが等しい文字列
a2 = 'あいうえお'
b2 = 'かきくけこ'

# (3) 30文字目で違うと分かる長さが等しい文字列
a3 = 'あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほ'
b3 = 'あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへぼ'

# (4) 31文字目で違うと分かるけど長さが違う文字列
a4 = 'あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほ'
b4 = 'あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほま'

# (5)Enum
from enum import Enum
Mode = Enum('Mode', ['normal', 'gray'])
a5 = Mode.normal
b5 = Mode.gray

これらを定義して、ipythonで以下のように%timeitマジックコマンドで調べましょう。
強く実装依存なのでこの通りにはならない可能性が高いですが、macOS CPython3.6.1 で

In [2]: %timeit a1==b1
45.1 ns ± 0.844 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [3]: %timeit a2==b2
53.7 ns ± 0.678 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [4]: %timeit a3==b3
56.5 ns ± 1.23 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [5]: %timeit a4==b4
43.7 ns ± 0.288 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [6]: %timeit a5==b5
52.1 ns ± 0.171 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

と、なって「長さが違う文字列」が比較が一番速いのです。

それも1億回実行して1秒違う程度です。あなたのプログラムはそれを気にするほどのことなのですか?
だったらそもそもPythonで書くべきではないと思いませんか?

これは「あとから分かりやすい」「バグを混入させにくい」ことを優先するべき事柄です。

Comments

[退会済みユーザー]

回答ありがとうございます。確かに言われてみれば、python使うんだったら速さを気にする必要はないかもしれませんね。これからは状況に応じてプログラムに必要な要素を考えてみることにしてみます。

[quickquip]

ちなみに「明らかに中身が違うリテラル同士を is 演算子で比較する」のが速いですね(一番かどうかは保証しかねますが) 。それでも、1億回実行して1秒違う程度でしかないどうでもいい話ですが。

Answer 2

**『複数の値を取りうるフラグ』**ってことですかね。
それでしたら列挙型というおあつらえ向きなものがあります。

from enum import Enum

Mode = Enum('Mode', ['normal', 'gray'])
image_mode = Mode.normal

event = True
if event:
    image_mode = Mode.gray
    
if image_mode is Mode.gray:
    print('hoge')

修正： 比較をisに変更。列挙型メンバーは同一性を比較できます
Wandbox

文字列よりは用途が明確でわかりやすいかと。

Comments

[退会済みユーザー]

回答ありがとうございます。確かに列挙型は見やすいですね。参考にさせていただきます。

Answer 3

いっそ紳士協定に任せる。

# constとして扱ってね
NORMAL = "標準"
GRAY = "グレースケール"

image_mode=NORMAL

#何らかのイベントが起きたら（ボタンが押されたとか）
if event==True:
    image_mode=GRAY

if image_mode is GRAY:  # is比較できるよやったね 
    #何らかの処理

pythonって実は日本語変数名も使えるから、こう書いたって良いはず（PEP8あたりで非推奨になってるはずだけど）。

# constとして扱ってね
標準 = "標準"
グレースケール = "グレースケール"

image_mode=標準

#何らかのイベントが起きたら（ボタンが押されたとか）
if event==True:
    image_mode=グレースケール

if image_mode is グレースケール:  # is比較できるよやったね 
    #何らかの処理

Answer 4

個人的な偏見なんですけど、文字列型って重そうなイメージがあるから、必要がなかったら使わないようにしていたんですけど

まさにそのとおりです。とりわけ、C言語などでは「文字列自体を単純に変数に入れられない」「文字列比較だけでも関数が必要になる」などの事情があって、全く実用性がありません。

ただ、言語によっては、「条件分岐の値として、単なる数値や文字列を使わななくてもいい」仕組みを用意しています。

• C言語…プリプロセッサマクロ
• Ruby…Symbol

Comments

[退会済みユーザー]

回答ありがとうございます。やはり文字列は重いのでできるだけ避けるようにします。