Pythonについて（アンチ専用）

1 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 10:24:06 .net] Pythonが嫌いな人のためのスレッドです。 ■関連スレ Rubyについて（アンチ専用） Part002 pc11.2ch.net/test/read.cgi/tech/1200210768/ 434 名前：デフォルトの名無しさん mailto:sage [2009/06/08(月) 22:30:34 .net] >>433 >明示的なだけで汚くはないだろ 明示しなきゃいけないんだから汚いだろー なんで抽象化されてないのさ >多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし は？そんなのふつうのメソッド呼び出しでも一緒じゃん class A(object): 　def f(self): print 'A' class B(object): 　def f(self): print 'B' class X(A, B): 　def g(self): 　　self.f()　　　# どの親クラスのメソッド呼ぶのか曖昧なの？ねえPythonってそうなの？ ふつうのメソッド呼び出しで行なっているのと同じルールを使って、親クラスのメソッドを呼べばいいだけじゃん。 もしPythonが本当に『どの親クラスのメソッド呼ぶのかさえ曖昧になる』んだったら、 もうsuper関係なしに、オブジェクト指向言語として失格だろwwwww >Python3からは引数省略してsuper().methできるらしいけど やっぱり多重継承関係ないじゃないかwwwww >>433は２行目で書いたことを３行目で忘れてるおばかさんーwwwww 435 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 00:19:05 .net] ようやくアンチスレらしくなって妙にうれしい 436 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 01:58:52 .net] >>434 そうだね、だから Python 3.0 では super() に self を明示しなくても良くなるよ。 今の Python は、 Python 2.2 までの古いクラスと新しいクラスが混在していて、 後方互換性の為には明示的にクラス名を書かないといけないの。 437 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 02:16:01 .net] 古いクラスと新しいクラスが混在って要・不要が議論されたあげくにそれか？ 自慢げに語ることじゃないだろ。　よほど言語設計として汚ないと思うが？ 438 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 02:22:03 .net] 2.xまで混在 3は新だけ 439 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 03:15:41 .net] >>437 Rubyとちがって、過去の資産を大切にするからね。 後方互換性を切る Py3k も数年がかりのプロジェクトになる。 新クラスは、必要と判断されたから導入された。でも、後方互換性の為に 旧クラスは残されている。 ruby の メソッドチェーンやブロック構文は、Pythonに導入しても「一部の人が 気持ちいい」とか「ときどき数タイプ減らせる」程度の効果しか認められないから Pythonには導入されない。 440 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 03:20:53 .net] >>426 > Pythonの配列操作がRubyと比べて面倒くさい > ttp://d.hatena.ne.jp/edvakf/20090405/1238885788 メソッドチェーンになれたRubyistがメソッドチェーンを無いことを反射的に 批判しているだけだろ。 文を分けないで関数を無制限にゴチャゴチャ繋げるのはPythonicではない。 一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は 文を分けるべき。文を分けたることによって数タイプ増えるが、その分可視性は 向上するので、トータルの生産性に大きな差は無い。それなら、すっきりした 書き方だけを使うのが Pythonic way. 441 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 04:00:06 .net] 久々に伸びてると思ったらなんじゃこりゃ 442 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 04:41:11 .net] >>432 同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。 言語仕様上の透明性を求めるか、表現式としての簡便さを求めるかの言語仕様上のトレードオフでしょ。 443 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 04:43:34 .net] >>426 > Pythonの配列操作がRubyと比べて面倒くさい > ttp://d.hatena.ne.jp/edvakf/20090405/1238885788 単に初学者が前に習った言語の作法にひきずられて 今学んでいる言語の流儀に逆らってるだけに見える。 444 名前：デフォルトの名無しさん [2009/06/09(火) 05:03:16 .net] rubyやJavaのメソッドチェーン使うときにいつも気になるのは 途中でメソッドの戻り値がぬるぽになるんじゃないかってところ だからpythonで文を分けて毎回if not hogeしている漏れは勝ち組 445 名前：デフォルトの名無しさん [2009/06/09(火) 05:13:49 .net] >なんか今更この記事にコメントが付きだしたのですが、どこかで紹介されたのでしょうか? 笑える >>426 > Pythonの配列操作がRubyと比べて面倒くさい > ttp://d.hatena.ne.jp/edvakf/20090405/1238885788 ruby a.sort().reverse().map{|x| x.to_s}.join('-') python '-'.join(map(lambda x:str(x), reversed(sorted(a)))) '-'.join(str(x) for x in reveresed(sorted(a))) '-'.join('%s'%(x) for x in sorted(a, reverse=True)) 確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？ 446 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 07:12:26 .net] >>436 なるほど、それが理由なのか。 じゃあ最初にオブジェクト指向機能を導入した時の設計が間違ってたんだな。 とりあえず「多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になる」と言いはるバカは消えろwww >>439 >Rubyとちがって、過去の資産を大切にするからね。 ちーがーうー、最初の設計が間違っていたから仕方なく過去を引きずっているだけwww それを「過去の資産を大切に」とかバカまるだしwww ほんとに大切にするなら3.0でも互換性をとっとけwww >>442 >同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。 ほんとにそう思う？ほんとにそう思うなら、親クラス名が省略できるようになった3.0は美しくないの？ 442にとっては3.0の仕様が美しくないそうだよwwww またバカ丸出しwwwwww Pythonistaは442みたいなのをだまらせとけやwww 身内の恥さらしだぞwwwwww 447 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 07:45:28 .net] 雑草が増えたな 448 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 08:14:19 .net] >>445 >python >'-'.join(map(lambda x:str(x), reversed(sorted(a)))) >'-'.join(str(x) for x in reveresed(sorted(a))) >'-'.join('%s'%(x) for x in sorted(a, reverse=True)) > >確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？ 厳密にひとつ、というわけじゃなくて、だいたい一つ、ぐらいの意味でいいんじゃない？ これくらいだったら十分許容範囲だろ。許してやれよ。 > ruby > a.sort().reverse().map{|x| x.to_s}.join('-') これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。 Pythonのは関数呼び出しが入れ子になっているからわかりずらい。 Python狂信者はこの事実を認めようとしないだろうけど。 >>440 >一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は >文を分けるべき。 それはPython限定の話だよね? 一息に書きにくい言語はそうすべきだけど、 一息にかける言語だったらそんなことに縛られる必要はまるでない。 >> 443 > 単に初学者が前に習った言語の作法にひきずられて > 今学んでいる言語の流儀に逆らってるだけに見える。 こういうやつがいるかぎりは、争いはいつまでたっても終わんないだろうね。 449 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 08:15:08 .net] ある種の若い男の子にありがちな語り口だよね。 わかるまいわかるまいと頑張りつつ、わからせる気も無い、のっけからの平行線狙いって。 場を味方につけつつ展開しないと、単に「こいつ一人が理解力無いだけ」って判断されて オシマイなんだけど。 450 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 08:17:25 .net] one liner書きにくすぎ インデント氏ね 451 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 08:47:16 .net] >>448 > > ruby > > a.sort().reverse().map{|x| x.to_s}.join('-') > > これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。 > Pythonのは関数呼び出しが入れ子になっているからわかりずらい。 > Python狂信者はこの事実を認めようとしないだろうけど。 python '-'.join(["%s"%(x) for x in sorted(a, reverse=True)]) これは全体の処理がトップダウンにきれいに流れるから読みやすいんだよね。 rubyのように処理順にすると最後にならないと全体の仕事がわからずに読み進めなきゃならない。 俺はruby狂信者なんてレッテルを貼ったりしないけど。 452 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 09:15:13 .net] >>445 その例だと、一番目は lambda が不要で '-'.join(map(str, sorted(a, reverse=True))) # もしくは itertools.imap 二番目は reversed が一つ余計で '-'.join(str(x) for x in sorted(a, reverse=True)) 三番目の % 記法を無理やり使うのは無いな。少なくとも (x,) としないと、 x 自体がタプル だったときに問題が起こる。 453 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 09:16:30 .net] >>444 確かに、Pythonの一行 = 1文 = 一つの事　という文化は、 例外発生時にスタックトレースを見るとすぐにどこが例外を 出したか特定できるという副次的な効果もあるねw 454 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 09:24:33 .net] >>448 > > ruby > > a.sort().reverse().map{|x| x.to_s}.join('-') > > これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。 > Pythonのは関数呼び出しが入れ子になっているからわかりずらい。 > Python狂信者はこの事実を認めようとしないだろうけど。 「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」 左から右なんだよね。なんで代入は右から左のままなの?代入演算子を => に すれば、 s = a.sort.reverse s.map{|x| x.to_s}.join('-') という風に代入が混じっていても、 a.sort.reverse=>s.map{|x| x.to_s}.join('-') って書けるのにさ。 結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい とか言っちゃってる気がしてならない。 あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは どうなんだ? Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという 方が分かり易いし正しいと思うぞ。 455 名前：デフォルトの名無しさん [2009/06/09(火) 12:21:12 .net] 末尾に!を付けると代入になるとかいいんじゃね 456 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 12:31:38 .net] >>454 「左から右」が好きなのは最近の人っつかRails厨に多い気がする (s = a.sort.reverse).map{|x| x.to_s}.join('-')で別に気にならないな 理屈は後付けで結局Matzの思いつきが多いのは然りごもっとも > あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは num.to_sとかの延長で考えると、別にいいんじゃねと思ってる 機能よりは主体がどっちなのかで分けてる感じかな、よくわからんが 457 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 12:40:48 .net] *リスト*を連結するのがstrのメソッドなのはいいのか？ 458 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 13:06:10 .net] リストの連結（リストをいくつか受け取って連結したリストを返す）メソッドがstrに定義されてる 言語なんてあるのか？ 459 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:29:46 .net] >>444 がっ! 460 名前：デフォルトの名無しさん [2009/06/09(火) 14:37:02 .net] >>453 それはたまたま副次的な効果が出たんじゃなくて 効果を期待してそのために文を分けてると思ってたｗ 461 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:38:58 .net] > ruby > a.sort().reverse().map{|x| x.to_s}.join('-') これ成城に動いてるときはいいんだけど バグが出たら何が原因か分かりづらいぜ？ 462 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:41:05 .net] >>454 >結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい >とか言っちゃってる気がしてならない。 そういう理由だったの？ Smalltalk から影響受けたんだと思ってたお 463 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:42:34 .net] >>457 リスト以外でも、イテレートできればなんでも連結できるよ? 464 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:43:05 .net] >>454 >「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」左から右なんだよね。 なんですべてを左から右にしようとしてんの？別に右から左でもいいけどさ、個々の処理がきれいに流れていることが重要なんじゃん。 unixのコマンドラインでパイプを使って処理を連結する感覚と一緒。Pythonとかだとそれがないってだけ。 >なんで代入は右から左のままなの?代入演算子を => にすれば、 >s = a.sort.reverse >s.map{|x| x.to_s}.join('-') >という風に代入が混じっていても、 >a.sort.reverse=>s.map{|x| x.to_s}.join('-') >って書けるのにさ。 そんなふうに書くわけないじゃん。 (s = a.sort.reverse).map{|x| x.to_s}.join('-') でいいだろ。自分で書いてて気づかないのか？ >結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい >とか言っちゃってる気がしてならない。 いや実際読みやすいだろ。 >あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのはどうなんだ? 連結した結果として文字列以外になんかあるか？joinは*要素を連結して*文字列として返すメソッドなんだから、リストのメソッドで何にもおかしくない。 > Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという方が分かり易いし正しいと思うぞ。 戻り値が文字列だからといって、要素を連結する機能を文字列に関する機能と考えるほうがどうかしてる。 joinはあくまで「要素を連結する」ためのメソッド。リストのメソッドで何が悪い。 >>452 おれもlambda x: str(x) とか書いてた！これはいらないのか！ちょー参考になった。さんくす。 465 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:44:06 .net] >>458 Java 466 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:47:34 .net] python は lisp と謂われる所以ですな 467 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:48:38 .net] >>452 今回はたまたまそれで良かった訳だが str() 以上に複雑なことさせようとしたら lambda 必要になるよね？ 468 名前：デフォルトの名無しさん [2009/06/09(火) 14:49:24 .net] 理想ばっか語ってても仕方ないよ 469 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:51:33 .net] >>464 例えば、xhtml を動的に生成する場合、 data = [tag.P(t) for t in "foo bar baz".split()] contents = tag.HR.join(data) print str(contents) で、 <p>foo</p> <hr/> <p>bar</p> <hr/> <p>baz</p> とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは 文字列処理にしか出てこないとは限らないだろ。 470 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 14:53:58 .net] >>467 それ以上に複雑になったら、mapではなくてリスト内包を使う。 リスト内包でもすっきり書けないくらい複雑になったら、ローカルで関数を定義して それを map する。 Pythonの関数は普通の変数と同じ名前空間に存在しているので扱いが楽。 471 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:01:41 .net] >>464 > (s = a.sort.reverse).map{|x| x.to_s}.join('-') これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、 そっからいきなり一番左に行って、代入結果に対してさらに右にとんで 処理しているんだよね? 俺は「左から右」のメソッドチェーンがPythonicな書き方に比べて特に 読みやすいとは思わないけど、もし「左から右に流れるように処理が連結 できる」のが本当に読みやすいのであれば、代入式も代入結果が式の値 なんだから代入結果を右に持っていくべきだよね。 Ruby厨ってRubyこそ正義って思って思考停止してない? 472 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:12:20 .net] pythonのlist.sort(), list.reverse()が処理後のリストを返さない理由を2文字で教えてください。 473 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:15:00 .net] >>471 464ではないし、Ruby触ったことないけど・・・ それは「コンピュータが処理をする順序の話」に寄りすぎちゃってない？ これって、「人間が動作の流れを目で追う話」だよね？ 俺が「一人の人間として」コードがやっていることを目で追うとき、 代入というのは「○○に××を代入する」行為であると捉えているから、 このコードは十分「左から右」になってるなぁ。 sにaをソートしてひっくり返したものを代入して、mapしてjoinする、って読む。 474 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:18:08 .net] >>470 mapとリスト内包ってどっちが速いん？ メモリ使用効率は？ 475 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:21:14 .net] 代入を右から左に「読む」という主張の人は、当然ながら a = b = c = 10 みたいなコードは、「10をcに代入し、その値をbに代入し・・・」って読み方なんだよね。 俺はそうじゃなくて、「aとbとcに10を代入する」って読む。 この認識が「コンピュータの動き」と異なっていることはわかっているけど、 でも自分が「プログラムの動き」からも離れて強引に左から右に読んでる、とも思わない。 476 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:21:47 .net] >>471 >> (s = a.sort.reverse).map{|x| x.to_s}.join('-') >これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、 >そっからいきなり一番左に行って、代入結果に対してさらに右にとんで >処理しているんだよね? いや、最初に「(s=」が目に入るからその時点で 脳内スタックに s の代入と s に対する次の 「).map」の準備が出来るから大丈夫 477 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:29:55 .net] Pythonのjoinが文字列のメソッドとなっているのは、単にリストだけでなくタプルや文字列やジェネレータのように 繰り返し可能なものすべてを扱えるようにしているからだよね。 だからほんとは join(iteratable, separator='') という関数でよかったんじゃないの？ joinが文字列のメソッドだからすごく違和感があるけど、単なる組み込み関数として存在するなら、別に違和感なし。 join(['a', 'b', 'c']) join(('a', 'b', 'c')) join(x for x in 'abc') 478 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:34:17 .net] >>465 Javaのどのメソッド? Stringクラスにはないけど。 479 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:36:29 .net] (s = a.sort.reverse).map{|x| x.to_s}.join('-') これを代入部分も含めたメソッドチェーン的に書き直すなら s.assign(a.sort.reverse).map{|x| x.to_s}.join('-') だろうね 480 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 15:38:11 .net] >>472 ヒントください 481 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 16:08:40 .net] >>469 >シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは >文字列処理にしか出てこないとは限らないだろ。 だったらなおさら文字列のメソッドにするべきじゃないだろ。 セパレータは文字列と限んないんだろ？joinを文字列のメソッドにしたら、セパレータは文字列限定じゃないか。 join(seq, sep='') のような組み込み関数にしとくべきだろ。 ''.join()が文字列しか対象としてないのを忘れて「文字列処理にしか出てこないとは限らない」とかバカじゃねーの 482 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 16:26:14 .net] map が map(func, list) の構造をしてるから join(sep='', seq=[]) になってた方がいいかな 483 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 16:27:37 .net] それどこのreduce 484 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 18:41:59 .net] join = lambda x, y: y.join(map(str, x)) 485 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 20:06:44 .net] すべてS式にすれば争いは起きないのに 486 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 20:38:36 .net] >>485 すべてS式にしたらしたでCLOSになって、 どれがマルチメソッドの第一引数になるかで揉める予感。 487 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:17:56 .net] >>472 in-place なメソッドだから。 488 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:21:16 .net] >>477 文字列に限定しないメソッドにする場合、まず　「つなぐ」　が何かを 定義しないと行けない。join を処理前の iteratable と切り離すのは 全く問題ないが、つないだ後の形と切り離して扱うのは効率が悪い。 489 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:22:22 .net] >>481 セパレータの型によってjoinの実装が変わるんだから、 文字列以外でjoinするときにはその型が自分でjoinを実装するべき。 490 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 22:26:46 .net] >>469 Python標準では str 以外で join() を実装しているのってあるの? hogehoge.join(['a','b','c']) # hogehoge は何か 文字列以外の join() が用意されてないなら、469のは説得力を感じないなあ。 491 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 22:58:11 .net] >>490 少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という 名前はスレッドの join であったり db の join であったりたくさんあるよ。 逆に、 str.join だと何か問題があるの？グローバルという特別な空間を 犯したり、リスト・タプル・その他すべてのイテレート可能型の名前空間に 文字列のための "join" メソッドをねじ込まないといけない理由は何？ 492 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 23:51:10 .net] >>491 >少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という >名前はスレッドの join であったり db の join であったりたくさんあるよ。 意味の違うjoinをもってきてどうすんの？ 今は hogehoge.join(seq) の形でリストやタプルを引数にとるものの話にきまってるだろ。 だれがスレッドのjoinの話をしてるの? Threadのjoinはlistに実装すべきだとかだれかいったの？ 話をすりかえんなよ。元の話は "".join(list) より list.join("") のほうが自然かどうかという話だろうが。 listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。 そこをおまえがセパレータが文字列じゃないjoin()もあるとか言い出したんだろ。 だからセパレータで文字列を使わないjoin()や、文字列以外での連結を行うjoin()は実際にあるのかと聞いたら、スレッドのjoinを挙げるなんて、バカすぎるわ。 リストやタプルの要素を連結する話なのに、スレッドやDBが関係あるわけないだろ。 「文字列以外の場合も考えられる」といっているけど、結局は具体例挙げられなくて、苦し紛れにjoinがつくものを挙げただけじゃんか。 おまえ反論したいだけだろ。「多重継承があるからsuperにはクラス名が必要」とか、いちいち理由をねつ造すんなよ。 つうかPythonistaはこんなやつほっとくなよ。Python界の恥さらしだろ。身内の恥は身内でなんとかしてくれ。 493 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:04:54 .net] >>492 お前こそ反論したいだけだろ。 >>491 は UserString という「同じ意味の」 join の反例を出している。 その上で、文字列以外にも join という名前はよくでてくるから文字列と 直接の関係がないリストに join という名前で文字列用のメソッドを 持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。 494 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:11:35 .net] RTFM ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method 495 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:18:58 .net] >>492 > listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。 joinはlistの要素を連結するんじゃないぞ。iterable であれば tuple でも generator でも なんでも使える。listのメソッドにしたらリストにしか使えない。これだけでもリストに join を 実装すべきでない明確な理由になるな。 496 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:19:00 .net] >>490 > Python標準では str 以外で join() を実装しているのってあるの? unicode.join() bytes.join() 497 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:19:46 .net] >>496 bytearray.join もだねw 498 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:47:47 .net] Python FAQにjoinのこと載ってあった。 4.8 Why is join() a string method instead of a list or tuple method? (なんでjoin()はlistやtupleのメソッドじゃなくてstringのメソッドなの?) ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method やっぱりみんな疑問に思うよな。思わないやつもいるけど。 FAQの答え This method can be used with any argument which obeys the rules for sequence objects, including any new classes you might define yourself. (このメソッドは、シーケンスオブジェクトのルールに則った引数なら何でも使うことができます。あなた自身が定義した新しいクラスでも構いません。) つまりlistやtuple以外でも、sequenceのように振る舞うものなら何でもjoinできるようにするために、joinをlistではなくstrのメソッドにしているわけだ。 >>477の通りだな。 Rubyだとmix-inがあるから、任意のクラスでEnumerableをincludeしてやればArrayじゃないものでもjoinが使えるようになるけど、 Pythonではそうするかわりに引数を抽象化することで、繰り返し可能であればなんでもjoinで使えるようになるということか。 これならjoinがstrのメソッドである理由として納得できるな。 Pythonでは多重継承できるんだからMix-inも使える。だからEnumerableを導入することは技術的には可能だけど、iteratableを引数にするという方法も悪くないね。 これでスッキリした。Pythonいいね! あとは多重継承が〜、joinは文字列を対象にしたメソッドだから〜、と、間違った理由をねつ造するバカを排除してくれ。 ほんとの理由を知らないくせに、分かったふりして語るなよな。答えしらないんなら出てくんな。 おまえリアルでも知ったかぶってるだろ。ほんと迷惑。 499 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 00:56:53 .net] なんでここIDでないんだろ 500 名前：デフォルトの名無しさん [2009/06/10(水) 00:59:11 .net] 迷惑な香具師に絡んで空気汚す香具師も迷惑 501 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:07:41 .net] >>493 >>>491 は UserString という「同じ意味の」 join の反例を出している。 なんでこれが反例なんだ？要素を連結して文字列を返しているんだからstr.joinとかわらない。 反例というなら、文字列じゃないセパレータを使って、要素の連結結果として文字列じゃないのを返すものをだせよ。 >その上で、文字列以外にも join という名前はよくでてくるから文字列と >直接の関係がないリストに join という名前で文字列用のメソッドを >持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。 だから、「joinが文字列用のメソッド」といいきれるのかという質問の答えになってないだろ。 おまえの話は、「joinは文字列用のメソッドであるのが自然」という前提から始まってるだろ。 その前提がおかしいんじゃないかって話をしているのに、名前空間なんか関係ないだろ。 はなっから質問が理解できてねーwww >>495 そういう納得できる回答がほしいわけよ。バカのねつ造にゲンナリしたから、もう自力で探したけど。 バカが理由もなく「joinは文字列用のメソッド」とかぬかしてるから、Rubyistごときに反論されるんじゃん。 ついでにいうと、それはjoinがlistやtupleのメソッドではない理由としては十分だけど、strのメソッドである理由としては不十分だけどな。 あとsuperでクラス名を指定しなきゃいけないのは、多重継承が原因じゃないからな。試験にでても間違えるなよ！ 502 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:13:40 .net] >>498 一つの理由を見つけただけですべてを判った気になるな。 ちゃんとそのFAQの最後に、 Because this is a string method it can work for Unicode strings as well as plain ASCII strings. If join() were a method of the sequence types then the sequence types would have to decide which type of string to return depending on the type of the separator. って書いてあるだろーが。 >>477,495 が正解であると同時に、「strのjoinだからstr.join」というのも 正解だ。 Rubyは自分で文字列と同じ振る舞いをする型を追加したら、 join_to_mystr なんてメソッドを Enumerable に追加するのか? 似たものを追加するときに同じ方法を一貫して使えるのが 正しい方法だ。 503 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:13:45 .net] >>461 >> ruby >> a.sort().reverse().map{|x| x.to_s}.join('-') > >これ成城に動いてるときはいいんだけど >バグが出たら何が原因か分かりづらいぜ？ Python: '-'.join(str(x) for x in sorted(a, reverse=True)) Pythonだって、バグが出たら同じようなもんじゃん。 504 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:18:58 .net] >>501 > なんでこれが反例なんだ？ > 要素を連結して文字列を返しているんだからstr.joinとかわらない。 strを拡張した型を作って join() したら元の str に戻ってしまうのが 正しい動作だと言うのか? Unicodeをjoin()した結果がstrになるのが正しい動作か? 505 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:29:17 .net] 同じFAQに、 "1, 2, 4, 8, 16".split(", ") が ", ".join([1,2,4,8,16]) と対称性が取れているという理由も載ってるね。 他の二つの理由と合わせて考えると、joinがstrのメソッドである事は とても合理的だと思える。 506 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:41:41 .net] 目的のものが作れればいいんじゃない？ 507 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 02:14:12 .net] >>481 要素の型が str, unicode, bytes 以外のシーケンスに対する join は、使う場面が 少ないとはいえ一般化して考えれば存在しうるんだから、実際に出てきたときに 対応できないのはまずいね。 検索してみたら、trac の html まわりでちょうど >>469 の言っていたような事を してる。 www.google.co.jp/codesearch/p?hl=ja#-EKtPk0GYAM/trac-0.10.3/trac/util/html.py&q=%22def%20join%22%20self&l=60 まぁ、一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の 連結メソッドを使うという解になるし、文字列は非常によく使う型だから一貫性から 飛び出した特別扱いにするというのも間違いではない。 あとは、「それがしっくりくる(気がする)」だけで特別扱いを許す緩いRubyと、 「明確なメリット無しに一貫性は壊さない」Python の違いでしかない。 結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい 程度の問題。 508 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 02:18:33 .net] >>505 それだ!! 509 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 06:43:49 .net] >>507 > 結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい > 程度の問題。 つまり結論は>>443ってことかよ。 510 名前：507 mailto:sage [2009/06/10(水) 11:05:32 .net] > 一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の > 連結メソッドを使うという解になるし、 typo 一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の 連結メソッドを入れるなという解になるし、 511 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 13:52:20 .net] >>502 それはダウトだろう。 今のjoinは単に u'a' + '' + u'b' + '' + u'c' のようなものだろ。 >>> ''.join([u'a',u'b',u'c']) u'abc' 「strのjoinだからstr」なんてことはない。 もしそうなら ''.join([1,2,3]) だって要素をすべてstr()にしてからjoinしてくれてもいいけど、ぜんぜんそうなってない。 どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。 Pythonの仕様上、joinをstrのメソッドにする理由はわかるけど、それが自然かどうかというのはまた別の話。 512 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 13:55:14 .net] >>502 >Rubyは自分で文字列と同じ振る舞いをする型を追加したら、 >join_to_mystr なんてメソッドを Enumerable に追加するのか? そうなったらjoinの引数として渡してやるだけでいいじゃん。 str.join(list) が list.join(str) となるだけ。 513 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 14:08:22 .net] >>502 >一つの理由を見つけただけですべてを判った気になるな。 その理由すらみつけられなかったやつがえらそうに。 最初からFAQを紹介しとけばよかったものを、シッタカブリのせいでぐちゃぐちゃ。 こいつリアルでもおんなじことしてんだろうな。だれもおまえの言葉、ありがたがってないから。 514 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 15:05:56 .net] 日本人はすぐ個人攻撃に走る 515 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 16:12:54 .net] 論理的に反論できないんですねわかります 516 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:01:21 .net] まぁ、論理的に反論できないやつが人格攻撃なんてよくあることだ罠 517 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:04:49 .net] 偉そうにはとても見えないけど、仮に偉そうだったとして、 実際この子よりは偉いだろうから仕方ないと思う。 相対的にこの子と対等かそれ以下になるのは、常人には逆に難しそう。 518 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:10:07 .net] >>511 > どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。 だから、どうしてstringのjoinしか見ないんだって何度もツッコミ入れられてるだろ。 joinがstringに定義されているから、引数はstringのiterableを取り、結果として連結されたstringを返す。 同様に、bytearrayのjoinは引数としてbytearrayのiterableを取り、結果として連結されたbytearrayを返す。 全部listのjoinが何とかするよりも、連結されるクラスが定義するpython式のほうがずっと自然だ。 519 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:11:18 .net] >>512 > そうなったらjoinの引数として渡してやるだけでいいじゃん。 > str.join(list) が list.join(str) となるだけ。 そのlistはstrのこともbytearrayのことも何でも知ってなきゃならないわけだ。 ユーザ定義のクラスを連結したい時にはどうするの？ 520 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:26:40 .net] その場合はlist.join内部を+とかconcatとかで実装しておいて その実装に使われたメソッドを各クラスで定義するのが自然ではなかろうか 一手間余計にかかるが 521 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:28:47 .net] 　　　　　　　_________ 　　　　　 ／　　　　 ＼ 　　　　／　　 ⌒　　⌒＼ 　　 ／　　 （ ⌒） 　（⌒）＼ 　　 i 　::::::⌒ （__人__） ⌒:: i 　　 　　　ヽ、　　　 `ー '　　 ／ 　　　 　/　　　　　┌─┐ 　　　 　i　　 丶　ヽ{ .茶 }ヽ 　　　 　ｒ 　 　 ヽ、__)一(_丿 　　　 　ヽ、___　　　ヽ　ヽ　 　　　　 と_＿＿_＿ノ＿ノ 522 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:33:39 .net] >>520 つまり連結演算子/連結関数を決め打ちするということね。 そんなことするぐらいならPythonのように連結されるクラスが提供するほうが 柔軟性があって、かつ、確実だと思うが。 523 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:35:48 .net] >>520 > その場合はlist.join内部を+とかconcatとかで実装しておいて それこそjoinのありがたみが台無しじゃん。 1つ1つ連結していたら計算量が大きくなるぞ。 524 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 17:47:46 .net] ＿＿ 　　　￣￣￣二二ニ＝- '''''"""￣￣ 　　　　　　　　　　　-=ﾆﾆﾆﾆ=- 　　　　　　　　　　　　　　　　　　　　　　 　　　／⌒ヽ　　　_,,-''" 　　　　　　　　　　　　　　　　　　　　　　 _　 ,（＾ω＾ ）　,-''";　　;, 　　　　　　　　　　　　　　　　　　 　 　 　 /　,_O_,,-''"';　',　:'　;;　;,' 　　　　　　　　　　　　　　　　　　　　　(.ﾞｰ'''",　;,;　'　;　;;　　':　　,' 　　　　　　　　　　　 　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　┼ヽ　 -|r‐､.　ﾚ　| 　　　　　　　　　　　　　 　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　　　　ｄ⌒)　./|　_ﾉ　 __ﾉ 525 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 19:56:04 .net] Rubyの方が「(Matzの)気持ちよさ」のために汎用性や効率を 犠牲にしている所が多いので、RubyとPythonの仕様の違いで 「Pythonが間違っている！」と指摘するRuby厨はたいてい 視野が狭い。 526 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 21:15:35 .net] >>525 おまえこそ視野を広く持てよ。 join()がArrayやListのメソッドである言語： Ruby, JavaScript, Smalltalk(GNU), Perl(List用の関数に分類される) join()が文字列のメソッドである言語： Python, C#, PHP(文字列用の関数に分類される) まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。 Pythonの場合はオブジェクト指向として考えたわけじゃなくて、シーケンスを引数にしたいという都合からそうなっているだけ。 joinを関数のようにとらえているとそれでもいいけど、オブジェクト指向的に考えると不自然ってだけ。 C#も、joinはインスタンスメソッドではなくスタティックメソッドだから、まさに関数的な考え方。 ttp://www.atmarkit.co.jp/fdotnet/dotnettips/366join/join.html joinは、オブジェクト指向が強い言語では当然のようにArrayやListのメソッドだけど、関数が主体の言語では文字列のメソッドになることがある。 少なくとも、joinが文字列のメソッドである*べき*なんてのはただのねつ造だし、言語でいえば実は少数派。 まあいいじゃん、joinが文字列のメソッドでも。PHPと同じだと思えば。 525の視野が広くなることを願いながら、この話題はここで終了。 527 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 22:00:10 .net] >>526が言語とライブラリの区別もつかない土方な件 528 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 22:04:40 .net] > まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。 ぷ オブジェクト指向的には"連結せよ"というメッセージは連結子になるオブジェクト(string)に送るのが自然だろ。 ArrayやListに送るという発想はSmalltalkの古いCollectionの設計に縛られているだけ。 529 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 22:08:45 .net] >>526 オブジェクト指向的かどうかではなくて、型に対する態度の問題だと思うぞ。 型を強く意識する言語では、文字列以外も入るリストに要素を文字列として 連結するなんてメソッドを追加するのはあり得ない。 C#のstaticmethod の join は、 Python にも string モジュールに join という関数がある。文字列に関連したメソッドなんだから str の インスタンスメソッドにした方が便利だから、インスタンスメソッドに なっただけ。 530 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 22:13:24 .net] 「オブジェクト指向的に自然」って、自分で思いこんでるのが すべての人にとっても自然だと考えるのはなんでなんだろうね。 少なくとも文字列の連結処理を効率的に行うには文字列の 実装を知らないといけなくて、Arrayが文字列の内部実装を 直接弄って効率的な連結をするのは気持ち悪いな。 531 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 00:45:49 .net] 理想の世界で生きていきたくても、 蛇にそそのかされてリンゴを食べたからな。 現実と向き合わないとならないのだよ。 532 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 01:13:38 .net] 　　　　　　＿＿＿＿＿_.＿＿＿＿＿_.__ 　　　　, '"――――‐, '"――――― ヽ`i1 　　　./ ∧＿∧　　 //'~￣￣|.|.|￣￣~|.||::|| 　　 .i　（・∀・ .）　　i !　　_,.＿|.|.| 　. 　 |.l|::|| 　[;].!_っ⌒'と　_0[;],l | 　f　_..┘|:.￣￣~ .|| ||.＿＿＿＿＿＿＿＿_, 　 ~l!=;:,...二二....,:;=iﾖ.'ｰ''"~ . __ !　　　 __.|| ||i リンゴジュース　￣i1 　　li..,._. ￣｡￣. _.,..!.|　　 ........~ﾉ..............~ || !|i,,＿__,,＿__,,＿__,,＿_,,!| 　　il＿｀}≡≡{´＿E|..::' /⌒ヽ'ヽ＿＿___/l|!=ｲ二/＿/ ⌒ヽヽ(ﾆ(] .　 {=i:::::::[二]:::::::i=i::｣　 |i.（*）.i;;;;|i□□ー‐! ::::::::::|;;;;;;|ii.（*） i;;;|二l] 　　￣￣ゞ三ノ ￣￣￣ゞ＿ノ￣　　ゞゞ三ノ 　　￣ゞゞ＿ノ~　　　　≡3 533 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 09:03:24 .net] >>511 >どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。 要素のすべてが文字列である場合じゃないとjoinできないんだから str/unicode/byteのメソッドなのでは？ 534 名前：494=502 mailto:sage [2009/06/11(木) 13:03:13 .net] >>513 俺は >>498 よりも先に >>494 を書いて、ちゃんと最後まで読んだ上で RTFM と言ったんだが?

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef