0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Pythonは辛い.しかし使う

Posted at

いろいろあってPythonを1年と少し書いている.(Not WEB系)

なんとなく見えてきたPythonの私なりの利点と辛い点をつらつらと挙げてみようかと(サボり).自分用のメモなのでまあそれなりに…ご指摘などいただければと.

Google先生へ,この記事を検索結果上位に標示することは検索を汚すだけなのでやめてくださいお願いします何でもします(何でもするとは言っていない.)

TL;DR

Pythonはいろいろと(私にとって)辛い仕様がある.

しかしながらそのデメリットを受け入れてでも使おうと思うほどの利点がるので仕方なく我々はPythonを使い続けるしか無いのではなかろうか…….

Pythonはつらい

ブロックの仕様が辛い

ご存知のようにPythonのインデントは意味を持つ.
インデントでブロックを構成するわけだ.

つまり,これ

if True:
   print("hoge")
else:
   print("piyo")
print("fuga")
# => hogeとfuga が表示される

とこれ

if True:
   print("hoge")
else:
   print("piyo")
   print("fuga")
# => hoge が表示される

では表示内容が異なる.

……わかってる.当たり前と言われることはわかっている.だが,考えてみてほしい.これ

if xxx:
   lorem
   if yyy:
      ipsum
      dolar
else:
   sit

とこれ

if xxx:
   lorem
   if yyy:
      ipsum
      dolar
   else:
      sit

の差はインデントだけであり,Emacsなどなどの自動インデント機能を使うとエディタ依存で構造が変わる.
これ,むしろ辛いと思わない人いるの?

何?みんな一発で正しいコード書いてるの?私はそんなことはできない.
ある程度のまとまりで関数を書くが,これはクラスまとまるぞ?ってなって全体をインデントしたり,
その後諸々内部のインデントが修正されたりする.
もちろん,ただ移設するだけの場合は行頭にスペースを必要個数追加すれば良いだけなので対応は可能である.
が,Cなどであればいらない1工程が挟まり,思考が止まる.とんでもないデメリットだと私は思う.

別に,常に中括弧で囲うことを強制しようというのではないが,オプショナルでできても良いではないか.

importの仕様が辛い

Pythonでは行頭にimportをづらづらと並べることが多いが,このときの検索パスが辛い.

プロジェクトのデフォルト構造が無いので(まあスクリプト言語だしこれは仕方なしか)決めにくいのはあるだろうが,
だからといって呼び方によって検索パスが変わるのはNG.

結局安心のためにsys.pathを編集してカレントディレクトリ配下を追加して…という作業が必要.

これは私の責任であるが,毎回この作業を忘れて,どうやってimoprtするんだっけと検索するはめになる.

map,filterの存在が辛い

Pythonは関数型言語に由来するmapやfilterが存在している.iterableが実装されているクラスに対して適応可能で,まあ名前の通りの動作をする.

lst: list = [1, 2, 3, 4, 5, 6]
lst2 = list(map(lambda x: x*2, lst))
lst3 = list(filter(lambda x: x % 2 == 0, lst))
print(lst2) # => [2, 4, 6, 8, 10, 12]
print(lst3) # => [2, 4, 6]

お気づきだろうか.私はわざわざmapなどの出力からlistへと変換している.
まあこれは別に辛いわけではないが微妙な気分になる.
結局,lambda x: iterable -> iterable であることだけが条件になるのでiterableであるmapの出力型になっているからで,変換が必要になるのは仕方のないことではある.

しかし実際は内包表記という便利な機能が備わっている.上と同じことが,

lst: list = [1, 2, 3, 4, 5, 6]
lst2 = [x * 2 for x in lst]
lst3 = [x for x in lst if x % 2 == 0]
print(lst2) # => [2, 4, 6, 8, 10, 12]
print(lst3) # => [2, 4, 6]

と書ける.

diskが辛い

Pythonはプロジェクトごとに仮想環境を切って使うのがなうい,らしい.
そこで私はPyenvでバージョンの切り替えを可能にし,pipenvでライブラリを環境ごとに切り替え可能としている.

問題はこれをやると仮想環境ごとにライブラリを持つなどしてどんどんディスクが食われていく.

速さを優先してM.2 SSDを使い,安いからといって250GB程度の環境だと地味に辛い.

これはに関しては,常にAnacondaやMinicondaなどの環境に引きこもってJupyterしている人には余り問題にならない話ではあるが.

Pythonはいいぞ

豊富なライブラリ

やりたいことを調べる -> ライブラリが見つかる というパターンの多さよ.
正直大抵のことはライブラリがあるのではと思う.

自然言語系で生きているので,MeCabやJuman++などを使うことがあるが,それらのラッパーも存在しているので
何も考えることなくPythonオブジェクトとして利用できる.便利.

形態素解析機くらいならまだ自前実装してもいいが,KNPなどの構文解析機のラッパーはあまりかきたくないのでとても助かる.

また,全角半角変換といった需要あるの?ということにも対応しているので,私はいろいろと先人の作ったライブラリを呼べば解決する.

機械学習系のライブラリは特に充実しているので,やりたいとおもったらとりあえずPythonするが吉.

Numpy,Pandas

もう,これだけでPython使う理由になりうるライブラリ.行列演算強すぎんよ……グラフ化しやすすぎんよ……

環境が切り分け可能

仮想環境で実行できるので,作成したプログラムをよそで動かすときにGlibcのバージョンがーなんて問題は気にしなくて良い.
良い.良い.

今人的にArch Linuxをつかっているので,余計に良い.

それでも我々はPythonを使う

上でいろいろ文句を言ったが,結局利点がでかすぎて我々はPythonから離れることができない.
Numpyが他の言語にもあれば……とも思うが,かと言ってRubyする気もなければPerlする気もないので,
都合の良いスクリプト言語としてもPythonが候補となってしまう.

設計で解決する問題は解決させつつ,使っていくしか無いのだろうな……

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?