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

■ このスレッドは過去ログ倉庫に格納されています
2008/02/21(木) 10:24:06
Pythonが嫌いな人のためのスレッドです。

■関連スレ
Rubyについて（アンチ専用） Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/
2009/05/02(土) 12:49:56
Pascal信者乙
2009/05/02(土) 18:43:36
Pascal 信者であれば begin, end が無いという
Ruby 信者でしょ
412デフォルトの名無しさん
垢版 |
2009/05/05(火) 22:06:13
行の開始位置が構造に関わるとか
COBOLかFORTRAN並みに古すぎとか
思ってたけど慣れるとなんでもない
endの方がきもい
漏れはRubyでも{}使う派なんだけど
Rubyは{}じゃだめでdo〜endでしか書けないケースが結構ありすぎ
2009/05/05(火) 23:27:06
>>412
Python型の行頭位置の規則（オフサイドルール）は、
言語の系譜としては現代的なものだぞ。他にHaskellとか。
2009/05/27(水) 11:52:20
> Rubyは{}じゃだめでdo〜endでしか書けないケースが結構ありすぎ
逆じゃないか？
Rubyの見栄え上do〜endのほうが良いなぁと思うのに、{}じゃないと書けないケースが多いと思う
2009/05/27(水) 11:58:10
多分個人のコーディングの癖（好むメソッドの組み合わせパターン）で
違ってくると思う。
2009/05/27(水) 13:38:02
>>412 書いたの漏れなんだが
なんであんなこと書いたのか
もう思い出せない orz
417デフォルトの名無しさん
垢版 |
2009/05/27(水) 17:06:12
>>409
end = Noneと書けばendが書けるよ
2009/05/27(水) 18:47:44
pass で閉じてる漏れは勝ち組み
2009/05/28(木) 10:06:56
>>414
foo hoge {
}
でfooにブロックをつけたいとかいうパターンだろう。
rake絡みなんかでよくある質問だな。
2009/05/28(木) 19:01:04
pythonはforが大杉。
2009/05/28(木) 19:29:27
安置というより無知を曝すスレだな
2009/06/08(月) 03:20:10
pythonスレはアforが大杉
2009/06/08(月) 03:21:36
自愛するべき
2009/06/08(月) 11:45:51
>>420
for で充分だから ブロック構文いらない。

Ruby厨はよく Pythonには○○が無いって叩くけど、大抵そういう機能は
Python-Idea ML で必要・不要が議論された結果不要と判断されている
ので、その機能が無くても同じ生産性をPythonは既に実現している。
2009/06/08(月) 13:22:44
for多すぎって[ ]の中じゃないの？
2009/06/08(月) 20:46:12
>>424
そうでもないだろ。

Pythonの配列操作がRubyと比べて面倒くさい
ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

それよりPythonはsuperのキモさをなんとかしてくれんかいのう。
なんでsuper()に親クラス名を指定しなきゃいかんの？ba
2009/06/08(月) 21:00:08
>>426
multi-inheritence dakara
2009/06/08(月) 21:06:58
>>427
多重継承はまったく関係ないよ。
つうかなんで多重継承が関係してくんの？
2009/06/08(月) 21:07:27
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

つ '-'.join(["%s"%(x) for x in sorted(a, reverse=True)])
2009/06/08(月) 21:08:35
私Ruby厨だけどsuperに関しては
superとsuper()で引数が違ってくるRubyの方がキモイと思う
2009/06/08(月) 21:13:13
>>426
> なんでsuper()に親クラス名を指定しなきゃいかんの？ba

Smalltalk系のようにsuperがcaller側のmethodのbindに依存するほうが
よほど言語設計として汚ないと思うが？
2009/06/08(月) 22:07:31
>>431
なんで汚いん?
「親クラス」という抽象的な表現ができず、具体的なクラス名をいちいち書かないといけないことは汚くないの？
2009/06/08(月) 22:15:57
明示的なだけで汚くはないだろ
多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
Python3からは引数省略してsuper().methできるらしいけど
2009/06/08(月) 22:30:34
>>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
2009/06/09(火) 00:19:05
ようやくアンチスレらしくなって妙にうれしい
2009/06/09(火) 01:58:52
>>434
そうだね、だから Python 3.0 では super() に self を明示しなくても良くなるよ。
今の Python は、 Python 2.2 までの古いクラスと新しいクラスが混在していて、
後方互換性の為には明示的にクラス名を書かないといけないの。
2009/06/09(火) 02:16:01
古いクラスと新しいクラスが混在って要・不要が議論されたあげくにそれか？
自慢げに語ることじゃないだろ。　よほど言語設計として汚ないと思うが？
2009/06/09(火) 02:22:03
2.xまで混在
3は新だけ
2009/06/09(火) 03:15:41
>>437
Rubyとちがって、過去の資産を大切にするからね。
後方互換性を切る Py3k も数年がかりのプロジェクトになる。

新クラスは、必要と判断されたから導入された。でも、後方互換性の為に
旧クラスは残されている。
ruby の メソッドチェーンやブロック構文は、Pythonに導入しても「一部の人が
気持ちいい」とか「ときどき数タイプ減らせる」程度の効果しか認められないから
Pythonには導入されない。
2009/06/09(火) 03:20:53
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788
メソッドチェーンになれたRubyistがメソッドチェーンを無いことを反射的に
批判しているだけだろ。

文を分けないで関数を無制限にゴチャゴチャ繋げるのはPythonicではない。
一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
文を分けるべき。文を分けたることによって数タイプ増えるが、その分可視性は
向上するので、トータルの生産性に大きな差は無い。それなら、すっきりした
書き方だけを使うのが Pythonic way.
2009/06/09(火) 04:00:06
久々に伸びてると思ったらなんじゃこりゃ
2009/06/09(火) 04:41:11
>>432
同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。
言語仕様上の透明性を求めるか、表現式としての簡便さを求めるかの言語仕様上のトレードオフでしょ。
2009/06/09(火) 04:43:34
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

単に初学者が前に習った言語の作法にひきずられて
今学んでいる言語の流儀に逆らってるだけに見える。
444デフォルトの名無しさん
垢版 |
2009/06/09(火) 05:03:16
rubyやJavaのメソッドチェーン使うときにいつも気になるのは
途中でメソッドの戻り値がぬるぽになるんじゃないかってところ
だからpythonで文を分けて毎回if not hogeしている漏れは勝ち組
445デフォルトの名無しさん
垢版 |
2009/06/09(火) 05:13:49
>なんか今更この記事にコメントが付きだしたのですが、どこかで紹介されたのでしょうか?
笑える

>>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って「やりかたはひとつ」を売りにしてなかったっけ？
2009/06/09(火) 07:12:26
>>436
なるほど、それが理由なのか。
じゃあ最初にオブジェクト指向機能を導入した時の設計が間違ってたんだな。
とりあえず「多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になる」と言いはるバカは消えろwww

>>439
>Rubyとちがって、過去の資産を大切にするからね。
ちーがーうー、最初の設計が間違っていたから仕方なく過去を引きずっているだけwww
それを「過去の資産を大切に」とかバカまるだしwww
ほんとに大切にするなら3.0でも互換性をとっとけwww

>>442
>同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。

ほんとにそう思う？ほんとにそう思うなら、親クラス名が省略できるようになった3.0は美しくないの？
442にとっては3.0の仕様が美しくないそうだよwwww またバカ丸出しwwwwww
Pythonistaは442みたいなのをだまらせとけやwww 身内の恥さらしだぞwwwwww
2009/06/09(火) 07:45:28
雑草が増えたな
2009/06/09(火) 08:14:19
>>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
> 単に初学者が前に習った言語の作法にひきずられて
> 今学んでいる言語の流儀に逆らってるだけに見える。
こういうやつがいるかぎりは、争いはいつまでたっても終わんないだろうね。
2009/06/09(火) 08:15:08
ある種の若い男の子にありがちな語り口だよね。
わかるまいわかるまいと頑張りつつ、わからせる気も無い、のっけからの平行線狙いって。
場を味方につけつつ展開しないと、単に「こいつ一人が理解力無いだけ」って判断されて
オシマイなんだけど。
2009/06/09(火) 08:17:25
one liner書きにくすぎ
インデント氏ね
2009/06/09(火) 08:47:16
>>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狂信者なんてレッテルを貼ったりしないけど。
2009/06/09(火) 09:15:13
>>445
その例だと、一番目は lambda が不要で
'-'.join(map(str, sorted(a, reverse=True))) # もしくは itertools.imap

二番目は reversed が一つ余計で
'-'.join(str(x) for x in sorted(a, reverse=True))

三番目の % 記法を無理やり使うのは無いな。少なくとも (x,) としないと、 x 自体がタプル
だったときに問題が起こる。
2009/06/09(火) 09:16:30
>>444
確かに、Pythonの一行 = 1文 = 一つの事　という文化は、
例外発生時にスタックトレースを見るとすぐにどこが例外を
出したか特定できるという副次的な効果もあるねw
2009/06/09(火) 09:24:33
>>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
末尾に!を付けると代入になるとかいいんじゃね
2009/06/09(火) 12:31:38
>>454
「左から右」が好きなのは最近の人っつかRails厨に多い気がする
(s = a.sort.reverse).map{|x| x.to_s}.join('-')で別に気にならないな
理屈は後付けで結局Matzの思いつきが多いのは然りごもっとも

> あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
num.to_sとかの延長で考えると、別にいいんじゃねと思ってる
機能よりは主体がどっちなのかで分けてる感じかな、よくわからんが
2009/06/09(火) 12:40:48
*リスト*を連結するのがstrのメソッドなのはいいのか？
2009/06/09(火) 13:06:10
リストの連結（リストをいくつか受け取って連結したリストを返す）メソッドがstrに定義されてる
言語なんてあるのか？
2009/06/09(火) 14:29:46
>>444
がっ!
460デフォルトの名無しさん
垢版 |
2009/06/09(火) 14:37:02
>>453
それはたまたま副次的な効果が出たんじゃなくて
効果を期待してそのために文を分けてると思ってたｗ
2009/06/09(火) 14:38:58
> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')

これ成城に動いてるときはいいんだけど
バグが出たら何が原因か分かりづらいぜ？
2009/06/09(火) 14:41:05
>>454
>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。

そういう理由だったの？
Smalltalk から影響受けたんだと思ってたお
2009/06/09(火) 14:42:34
>>457
リスト以外でも、イテレートできればなんでも連結できるよ?
2009/06/09(火) 14:43:05
>>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) とか書いてた！これはいらないのか！ちょー参考になった。さんくす。
2009/06/09(火) 14:44:06
>>458
Java
2009/06/09(火) 14:47:34
python は lisp と謂われる所以ですな
2009/06/09(火) 14:48:38
>>452
今回はたまたまそれで良かった訳だが
str() 以上に複雑なことさせようとしたら lambda 必要になるよね？
468デフォルトの名無しさん
垢版 |
2009/06/09(火) 14:49:24
理想ばっか語ってても仕方ないよ
2009/06/09(火) 14:51:33
>>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>
とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
文字列処理にしか出てこないとは限らないだろ。
2009/06/09(火) 14:53:58
>>467
それ以上に複雑になったら、mapではなくてリスト内包を使う。
リスト内包でもすっきり書けないくらい複雑になったら、ローカルで関数を定義して
それを map する。

Pythonの関数は普通の変数と同じ名前空間に存在しているので扱いが楽。
2009/06/09(火) 15:01:41
>>464
> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
処理しているんだよね?

俺は「左から右」のメソッドチェーンがPythonicな書き方に比べて特に
読みやすいとは思わないけど、もし「左から右に流れるように処理が連結
できる」のが本当に読みやすいのであれば、代入式も代入結果が式の値
なんだから代入結果を右に持っていくべきだよね。

Ruby厨ってRubyこそ正義って思って思考停止してない?
2009/06/09(火) 15:12:20
pythonのlist.sort(), list.reverse()が処理後のリストを返さない理由を2文字で教えてください。
2009/06/09(火) 15:15:00
>>471
464ではないし、Ruby触ったことないけど・・・
それは「コンピュータが処理をする順序の話」に寄りすぎちゃってない？
これって、「人間が動作の流れを目で追う話」だよね？

俺が「一人の人間として」コードがやっていることを目で追うとき、
代入というのは「○○に××を代入する」行為であると捉えているから、
このコードは十分「左から右」になってるなぁ。
sにaをソートしてひっくり返したものを代入して、mapしてjoinする、って読む。
2009/06/09(火) 15:18:08
>>470
mapとリスト内包ってどっちが速いん？
メモリ使用効率は？
2009/06/09(火) 15:21:14
代入を右から左に「読む」という主張の人は、当然ながら
a = b = c = 10
みたいなコードは、「10をcに代入し、その値をbに代入し・・・」って読み方なんだよね。
俺はそうじゃなくて、「aとbとcに10を代入する」って読む。

この認識が「コンピュータの動き」と異なっていることはわかっているけど、
でも自分が「プログラムの動き」からも離れて強引に左から右に読んでる、とも思わない。
2009/06/09(火) 15:21:47
>>471
>> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
>これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
>そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
>処理しているんだよね?

いや、最初に「(s=」が目に入るからその時点で
脳内スタックに s の代入と s に対する次の
「).map」の準備が出来るから大丈夫
2009/06/09(火) 15:29:55
Pythonのjoinが文字列のメソッドとなっているのは、単にリストだけでなくタプルや文字列やジェネレータのように
繰り返し可能なものすべてを扱えるようにしているからだよね。

だからほんとは
join(iteratable, separator='')
という関数でよかったんじゃないの？
joinが文字列のメソッドだからすごく違和感があるけど、単なる組み込み関数として存在するなら、別に違和感なし。

join(['a', 'b', 'c'])
join(('a', 'b', 'c'))
join(x for x in 'abc')
2009/06/09(火) 15:34:17
>>465
Javaのどのメソッド? Stringクラスにはないけど。
2009/06/09(火) 15:36:29
(s = a.sort.reverse).map{|x| x.to_s}.join('-')
これを代入部分も含めたメソッドチェーン的に書き直すなら
s.assign(a.sort.reverse).map{|x| x.to_s}.join('-')
だろうね
2009/06/09(火) 15:38:11
>>472
ヒントください
2009/06/09(火) 16:08:40
>>469
>シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
>文字列処理にしか出てこないとは限らないだろ。
だったらなおさら文字列のメソッドにするべきじゃないだろ。
セパレータは文字列と限んないんだろ？joinを文字列のメソッドにしたら、セパレータは文字列限定じゃないか。
join(seq, sep='') のような組み込み関数にしとくべきだろ。
''.join()が文字列しか対象としてないのを忘れて「文字列処理にしか出てこないとは限らない」とかバカじゃねーの
2009/06/09(火) 16:26:14
map が map(func, list) の構造をしてるから
join(sep='', seq=[])
になってた方がいいかな
2009/06/09(火) 16:27:37
それどこのreduce
2009/06/09(火) 18:41:59
join = lambda x, y: y.join(map(str, x))
2009/06/09(火) 20:06:44
すべてS式にすれば争いは起きないのに
2009/06/09(火) 20:38:36
>>485
すべてS式にしたらしたでCLOSになって、
どれがマルチメソッドの第一引数になるかで揉める予感。
2009/06/09(火) 21:17:56
>>472
in-place なメソッドだから。
2009/06/09(火) 21:21:16
>>477
文字列に限定しないメソッドにする場合、まず　「つなぐ」　が何かを
定義しないと行けない。join を処理前の iteratable と切り離すのは
全く問題ないが、つないだ後の形と切り離して扱うのは効率が悪い。
2009/06/09(火) 21:22:22
>>481
セパレータの型によってjoinの実装が変わるんだから、
文字列以外でjoinするときにはその型が自分でjoinを実装するべき。
2009/06/09(火) 22:26:46
>>469
Python標準では str 以外で join() を実装しているのってあるの?
hogehoge.join(['a','b','c']) # hogehoge は何か
文字列以外の join() が用意されてないなら、469のは説得力を感じないなあ。
2009/06/09(火) 22:58:11
>>490
少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
名前はスレッドの join であったり db の join であったりたくさんあるよ。

逆に、 str.join だと何か問題があるの？グローバルという特別な空間を
犯したり、リスト・タプル・その他すべてのイテレート可能型の名前空間に
文字列のための "join" メソッドをねじ込まないといけない理由は何？
2009/06/09(火) 23:51:10
>>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界の恥さらしだろ。身内の恥は身内でなんとかしてくれ。
2009/06/10(水) 00:04:54
>>492
お前こそ反論したいだけだろ。
>>491 は UserString という「同じ意味の」 join の反例を出している。

その上で、文字列以外にも join という名前はよくでてくるから文字列と
直接の関係がないリストに join という名前で文字列用のメソッドを
持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。
2009/06/10(水) 00:11:35
RTFM
ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method
2009/06/10(水) 00:18:58
>>492
> listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
joinはlistの要素を連結するんじゃないぞ。iterable であれば tuple でも generator でも
なんでも使える。listのメソッドにしたらリストにしか使えない。これだけでもリストに join を
実装すべきでない明確な理由になるな。
2009/06/10(水) 00:19:00
>>490
> Python標準では str 以外で join() を実装しているのってあるの?

unicode.join()
bytes.join()
2009/06/10(水) 00:19:46
>>496
bytearray.join もだねw
2009/06/10(水) 00:47:47
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は文字列を対象にしたメソッドだから〜、と、間違った理由をねつ造するバカを排除してくれ。
ほんとの理由を知らないくせに、分かったふりして語るなよな。答えしらないんなら出てくんな。
おまえリアルでも知ったかぶってるだろ。ほんと迷惑。
2009/06/10(水) 00:56:53
なんでここIDでないんだろ
500デフォルトの名無しさん
垢版 |
2009/06/10(水) 00:59:11
迷惑な香具師に絡んで空気汚す香具師も迷惑
2009/06/10(水) 01:07:41
>>493
>>>491 は UserString という「同じ意味の」 join の反例を出している。
なんでこれが反例なんだ？要素を連結して文字列を返しているんだからstr.joinとかわらない。
反例というなら、文字列じゃないセパレータを使って、要素の連結結果として文字列じゃないのを返すものをだせよ。

>その上で、文字列以外にも join という名前はよくでてくるから文字列と
>直接の関係がないリストに join という名前で文字列用のメソッドを
>持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。
だから、「joinが文字列用のメソッド」といいきれるのかという質問の答えになってないだろ。
おまえの話は、「joinは文字列用のメソッドであるのが自然」という前提から始まってるだろ。
その前提がおかしいんじゃないかって話をしているのに、名前空間なんか関係ないだろ。
はなっから質問が理解できてねーwww

>>495
そういう納得できる回答がほしいわけよ。バカのねつ造にゲンナリしたから、もう自力で探したけど。
バカが理由もなく「joinは文字列用のメソッド」とかぬかしてるから、Rubyistごときに反論されるんじゃん。

ついでにいうと、それはjoinがlistやtupleのメソッドではない理由としては十分だけど、strのメソッドである理由としては不十分だけどな。

あとsuperでクラス名を指定しなきゃいけないのは、多重継承が原因じゃないからな。試験にでても間違えるなよ！
2009/06/10(水) 01:13:40
>>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 に追加するのか?
似たものを追加するときに同じ方法を一貫して使えるのが
正しい方法だ。
2009/06/10(水) 01:13:45
>>461
>> ruby
>> a.sort().reverse().map{|x| x.to_s}.join('-')
>
>これ成城に動いてるときはいいんだけど
>バグが出たら何が原因か分かりづらいぜ？

Python:
'-'.join(str(x) for x in sorted(a, reverse=True))

Pythonだって、バグが出たら同じようなもんじゃん。
2009/06/10(水) 01:18:58
>>501
> なんでこれが反例なんだ？
> 要素を連結して文字列を返しているんだからstr.joinとかわらない。

strを拡張した型を作って join() したら元の str に戻ってしまうのが
正しい動作だと言うのか?
Unicodeをjoin()した結果がstrになるのが正しい動作か?
2009/06/10(水) 01:29:17
同じFAQに、
"1, 2, 4, 8, 16".split(", ")
が
", ".join([1,2,4,8,16])
と対称性が取れているという理由も載ってるね。
他の二つの理由と合わせて考えると、joinがstrのメソッドである事は
とても合理的だと思える。
2009/06/10(水) 01:41:41
目的のものが作れればいいんじゃない？
2009/06/10(水) 02:14:12
>>481
要素の型が str, unicode, bytes 以外のシーケンスに対する join は、使う場面が
少ないとはいえ一般化して考えれば存在しうるんだから、実際に出てきたときに
対応できないのはまずいね。

検索してみたら、trac の html まわりでちょうど >>469 の言っていたような事を
してる。
http://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 の違いでしかない。

結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
程度の問題。
2009/06/10(水) 02:18:33
>>505
それだ!!
2009/06/10(水) 06:43:49
>>507
> 結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
> 程度の問題。

つまり結論は>>443ってことかよ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況