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

**デフォルトの名無しさん** · 2008/02/21(木) 10:24:06

Pythonが嫌いな人のためのスレッドです。

■関連スレ
Rubyについて（アンチ専用） Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/

**デフォルトの名無しさん** · 2009/03/20(金) 17:33:56

Pythonのドキュメントは愛がたりない
Rubyみたいなドキュメントになってほしい

**デフォルトの名無しさん** · 2009/03/20(金) 18:44:16

未完成な「Rubyリファレンスマニュアル刷新計画 chm版」というのを
ダウンロードしてみたけど、Rubyのほうがちゃんと気合い入ってそうだ。

**デフォルトの名無しさん** · 2009/03/20(金) 18:51:11

>>392
http://docs.python.org/search.html?q=defaultdict

2.6系からドキュメントシステムが変わりました…
Json のindexを構築して検索してるそうな…
sphinx + Pygments とかでぐぐると嬉しい
http://sphinx.pocoo.org/

**デフォルトの名無しさん** · 2009/03/20(金) 19:46:37

左側の無駄なスペース無くして欲しいんだが
それにフォントもでかくなってて読みにくい
使い勝手は良くなったのかも知れないが
生理的に受け付けなくなりつつある

**デフォルトの名無しさん** · 2009/03/20(金) 19:48:17

もっとサクサク動くようにするべきだと思う

**デフォルトの名無しさん** · 2009/03/20(金) 23:12:49

オライリー本のヘビの絵がきもい。

**デフォルトの名無しさん** · 2009/03/20(金) 23:23:39

Twisted本はさらにひどい。
しかしそれはオライリーに文句を言うべき

**デフォルトの名無しさん** · 2009/03/20(金) 23:38:10

>>397
俺もそれはウザいと思っていたのでスタイルシート弄った

**デフォルトの名無しさん** · 2009/03/21(土) 00:36:31

前は気軽にプリントアウト出来てたのに

**デフォルトの名無しさん** · 2009/03/25(水) 05:04:28

>401
こういう時、ユーザスタイルシートって有難いな

**デフォルトの名無しさん** · 2009/04/10(金) 08:27:17

>>397
>左側の無駄なスペース
目次用のエリアじゃないのか？

**デフォルトの名無しさん** · 2009/04/29(水) 06:08:22

pythonは速いと聞いたので覚えようと思ったけど文法が訳ワカメで難しすぎて無理
もっと、こっからここまでをバシっと決めてくれないかなぁ

**デフォルトの名無しさん** · 2009/04/29(水) 12:54:20

Cにしとけ

**デフォルトの名無しさん** · 2009/04/29(水) 19:42:51

早いのがいいならFORTRANだろ

**デフォルトの名無しさん** · 2009/05/02(土) 01:48:08

>>405
Pythonで文法がわかりにくいというのは初めて聞いた
具体的にどこがわかりにくいのだろうか

**デフォルトの名無しさん** · 2009/05/02(土) 12:18:35

endがなくてキモい

**デフォルトの名無しさん** · 2009/05/02(土) 12:49:56

Pascal信者乙

**デフォルトの名無しさん** · 2009/05/02(土) 18:43:36

Pascal 信者であれば begin, end が無いという
Ruby 信者でしょ

**デフォルトの名無しさん** · 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

**デフォルトの名無しさん** · 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

単に初学者が前に習った言語の作法にひきずられて
今学んでいる言語の流儀に逆らってるだけに見える。

**デフォルトの名無しさん** · 2009/06/09(火) 05:03:16

rubyやJavaのメソッドチェーン使うときにいつも気になるのは
途中でメソッドの戻り値がぬるぽになるんじゃないかってところ
だからpythonで文を分けて毎回if not hogeしている漏れは勝ち組

**デフォルトの名無しさん** · 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() の方が、文字列に関する機能は文字列のメソッドという
方が分かり易いし正しいと思うぞ。

**デフォルトの名無しさん** · 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
がっ!

**デフォルトの名無しさん** · 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 必要になるよね？

**デフォルトの名無しさん** · 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)
で、
foo
<hr/>
bar
<hr/>
baz
とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
文字列処理にしか出てこないとは限らないだろ。

**デフォルトの名無しさん** · 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