だいたいどうでもいい内容

思考の整理のために書いてるので書き直しとか普通。あと中の人はイカレなので注意。

あのつらぽよの byte - str 問題はどうなった……

やっと彼らは「今年こそPython3が来る」と言わなくてもよくなったやつ

ということで 2020/1/1 にPython2のEOLが決まったので、パイソニスタの人たちは「今年からPython3が来る!」ともう言わなくても済むようになったようではあります。

Python 2の終了日が2020年1月1日に決定

個人的にはPythonはよー使わんのでアレですがまだまだbyteとstrのアレが……いえなんでもないです、おめでとうございます。

なお、systemだか何だかでシェル蹴って受け取った文字列を別に使おうとするとLinuxではOK、Windowsだとダメ問題は仕様扱いのため残存中。

窓OSの人は正しいやり方は一つとか言ってたら刺される場合があるのでご注意ください。残念ですがそういうコードを書いたら正しいやり方は窓OSで一つ、Un*x系で一つ、つまり二つ! いやったあああああああああ!(吐血

個人的雑感

Java - C#Python - Rubyの比較が一番あるあるなんでアレなんですが。

Java/Python組はどちらも言語仕様という意味ではコンパクトなので移植が容易とか、コードジェネレータのベースとして使いやすい特性があります(Javaが一番ジェネレータの素材にされやすいですが)。逆に言語仕様が貧弱ともいえるわけで、言語特有のお作法が多いのが難点かなぁとは。初心者でも分かるのは「StringBuffer」的なモノ(Pythonにもあります)とか、Javaの「なんでも継承頼み」のことです。

過去のJavaは「デザパタ」は常識、継承しまくりが普通でしたでしょう。interfaceの「中身」を持ち越せる機能をもっと早く提供していればクソ継承ツリーなクラス爆発はだいぶマシだったと思います。あともっとマシなLambdaとかでしょうか。

Python固有事情は過去にもチラっと「CJKV塩対応」とか「『}』とか『end』に類するものがないので分岐・ループの末尾が分かりにくい」とか書きましたし、後付けでクラス盛って運用でカバー方式が多いとか、その辺もあってあんまり使ってはおりません。

CJKVが塩、が一番の理由ですけど(数値計算はあんまやりませんよ)。

end 絡みはHaskellも同様なんで……うーん、なんか数学とか計算機工学系の人らは「END不要・インデントでブロック作るのが美しい」という何かがあるんでしょうか?

C#/Rubyはまるっと逆ですが、利点も飛んでるというくらい。融通は利きますが、移植性の観点では相当に労力を要するでしょう。

更なる個人的には

以前にも書いてるんですがあの str.encode とか byte.decode (アレ?)がどうにも。Pythonから見たらあってるんですが書いてる側からすると逆なわけで時々自分の足を打ち……アレ本当になんとかならないですかね。

よくわからんものをPythonが分かるユニコちゃんにするdecode、ユニコードを(Pythonからみて)よー分からんものにするencode、で合ってるっちゃ合ってるんですが、ゴリゴリ書いてるときに頭の中でエン/デコが逆になってキレそうになったことは何度も。

ピンとこない古参のマに言うと

「Python3の文字列の扱いは ADODB.Stream っぽい」

と言えばわかるでしょうか? UTF-8とかユニコちゃんで配慮されてる英語以外のすべての言語でイミフな変換作業への配慮を要すというあのいら立ち感が常に付きまとう……!

あれが無ければPython使ってた気もしますががが。後発のRubyの方がマルチバイト・ユニコちゃん・UTF-8対応は上手いが故に「文系向け言語」とも呼ばれるわけでしょうが。

現状のPythonは「無償のMATLAB」的な方向性に行きつつあるようですし、数字扱う人が文字列どうこうとかは気にしないので、さほど問題はなかったのでしょう。NumPyとか対応早かったじゃあないですか。

ただ、あのPython3の仕様変更で「paramiko」とかはワリを食ったわけですし、ぱらみこさんを裏で使うansibleがいつまでもPython3ではunstable扱いとか……めんどくさい話はあったことだけは指摘できます。

あとansibleで思い出したんですが、jinja2はごめん無理感パないというかループ外の変数あるじゃないスか、条件分岐・ループ内で書き換えたはずの変数が分岐抜けたら元通りとか、なんでなんスかっつってansibleというか、テンプレートエンジンとか、Pythonを諦めたことが。Pythonで複数行Lambdaをキメるときと同程度にメンドクサいハックをざるを得なくなります。

いやjinja1はそうじゃなかっただろ? なんでラダーとかHDLくらい融通利かん仕様になってるんだよ?

いやもうどうでもいいです。どうでもよくなってきた。

少なくとも、数値計算をやらん僕にはPythonはあまり触る機会のない言語ではあります。いやそもそもIT廃業の準備中な気はしますのでこんな話書いてもしようがない気はしますが?

余談のPythonistaとRubyistの気質の違い

Pythonistaの場合、PythonRubyを実装するような謎い傾向があります。正確にはPyPyという実験用言語だったと思いますが、研究者っぽいっちゃあそんな感じ。

Rubyistは「ああPython数値計算うまいしRubyは無理だね、じゃあPythonにやらせて結果パクるわ(そういうGem書いた人がいます)」という、使えれば何でもええわと言う実用主義者の適当さが。

あとRubyの強みはLambda最強伝説かとは。僕は何度かその辺で助けられてはいますのでRubyistであるのは認めます。

ザクっとLambdaを説明すると「処理そのものを乗っ取るとか、処理の途中での別処理を差し込むための最も手っ取り早い方法」という感じです。高階関数としての使い方が一番多いと思いますが。「一部分だけ別処理ぶっこめたら全部まるっと処理できるのになあ!」ってときに重宝します。ハマると脳汁ドバドバかつ、interfaceとかメソッドオーバーライドをゴネるよりスッキリです。

Pythonは(いちおう)ラムダ「式」扱いですんで……ラムダ計算は、恐らく数学とは相容れないんでしょう。

Lambdaは多様性の証明をやってるので、Pythonの主義とは相容れません。

述語は複数あってもいい(やり方はひとつじゃない)と証明したのがLambdaなので。

厄介なことに工学系領域では「ほぼほぼ一つにまで洗練された解法」を求められるのは事実で、ここにPythonはハマります。工学領域ではシクったら人死にが出るので、保守的であるべきです。

ある意味Pythonは(ヘイトしているわけではなく安定性を求める意味で)保守的、Rubyはゴリゴリの革新派(Web系とかGemのはっちゃけっぷり)と解釈していきたいものです。

目の前の問題を解決できるならどっちでもいいんでしょうが……バランスは維持したいものです。

今日の問題を解決できないなら明日はありゃしませんが、特定の方法を信奉してたらいつかやられますので、ある程度の柔軟性はほしいところですか。

個人的には妥当なやり方を3コ考えられないなら設計シクってると踏んで再考する程度です……ええ、僕は皆様のご想像通りボンクラなのですみませんでした orz