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

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

■関連スレ
Rubyについて（アンチ専用） Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/
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ってことかよ。
510507
垢版 |
2009/06/10(水) 11:05:32
> 一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
> 連結メソッドを使うという解になるし、
typo
一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
連結メソッドを入れるなという解になるし、
2009/06/10(水) 13:52:20
>>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のメソッドにする理由はわかるけど、それが自然かどうかというのはまた別の話。
2009/06/10(水) 13:55:14
>>502
>Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
>join_to_mystr なんてメソッドを Enumerable に追加するのか?

そうなったらjoinの引数として渡してやるだけでいいじゃん。
str.join(list) が list.join(str) となるだけ。
2009/06/10(水) 14:08:22
>>502
>一つの理由を見つけただけですべてを判った気になるな。
その理由すらみつけられなかったやつがえらそうに。
最初からFAQを紹介しとけばよかったものを、シッタカブリのせいでぐちゃぐちゃ。
こいつリアルでもおんなじことしてんだろうな。だれもおまえの言葉、ありがたがってないから。
2009/06/10(水) 15:05:56
日本人はすぐ個人攻撃に走る
2009/06/10(水) 16:12:54
論理的に反論できないんですねわかります
2009/06/10(水) 17:01:21
まぁ、論理的に反論できないやつが人格攻撃なんてよくあることだ罠
2009/06/10(水) 17:04:49
偉そうにはとても見えないけど、仮に偉そうだったとして、
実際この子よりは偉いだろうから仕方ないと思う。
相対的にこの子と対等かそれ以下になるのは、常人には逆に難しそう。
2009/06/10(水) 17:10:07
>>511
> どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

だから、どうしてstringのjoinしか見ないんだって何度もツッコミ入れられてるだろ。
joinがstringに定義されているから、引数はstringのiterableを取り、結果として連結されたstringを返す。
同様に、bytearrayのjoinは引数としてbytearrayのiterableを取り、結果として連結されたbytearrayを返す。
全部listのjoinが何とかするよりも、連結されるクラスが定義するpython式のほうがずっと自然だ。
2009/06/10(水) 17:11:18
>>512
> そうなったらjoinの引数として渡してやるだけでいいじゃん。
> str.join(list) が list.join(str) となるだけ。

そのlistはstrのこともbytearrayのことも何でも知ってなきゃならないわけだ。
ユーザ定義のクラスを連結したい時にはどうするの？
2009/06/10(水) 17:26:40
その場合はlist.join内部を+とかconcatとかで実装しておいて
その実装に使われたメソッドを各クラスで定義するのが自然ではなかろうか
一手間余計にかかるが
2009/06/10(水) 17:28:47
　　　　　　　_________
　　　　　 ／　　　　 ＼
　　　　／　　 ⌒　　⌒＼
　　 ／　　 （ ⌒） 　（⌒）＼
　　 i 　::::::⌒ （__人__） ⌒:: i 　　
　　　ヽ、　　　 `ー '　　 ／
　　　 　/　　　　　┌─┐
　　　 　i　　 丶　ヽ{ .茶 }ヽ
　　　 　ｒ 　 　 ヽ、__)一(_丿
　　　 　ヽ、___　　　ヽ　ヽ　
　　　　 と_＿＿_＿ノ＿ノ
2009/06/10(水) 17:33:39
>>520
つまり連結演算子/連結関数を決め打ちするということね。
そんなことするぐらいならPythonのように連結されるクラスが提供するほうが
柔軟性があって、かつ、確実だと思うが。
2009/06/10(水) 17:35:48
>>520
> その場合はlist.join内部を+とかconcatとかで実装しておいて

それこそjoinのありがたみが台無しじゃん。
1つ1つ連結していたら計算量が大きくなるぞ。
2009/06/10(水) 17:47:46
＿＿
　　　￣￣￣二二ニ＝-
'''''"""￣￣
　　　　　　　　　　　-=ﾆﾆﾆﾆ=-


　　　　　　　　　　　　　　　　　　　　　　 　　　／⌒ヽ　　　_,,-''"
　　　　　　　　　　　　　　　　　　　　　　 _　 ,（＾ω＾ ）　,-''";　　;,
　　　　　　　　　　　　　　　　　　 　 　 　 /　,_O_,,-''"';　',　:'　;;　;,'
　　　　　　　　　　　　　　　　　　　　　(.ﾞｰ'''",　;,;　'　;　;;　　':　　,'
　　　　　　　　　　　 　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　┼ヽ　 -|r‐､.　ﾚ　|
　　　　　　　　　　　　　 　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　　　　ｄ⌒)　./|　_ﾉ　 __ﾉ
2009/06/10(水) 19:56:04
Rubyの方が「(Matzの)気持ちよさ」のために汎用性や効率を
犠牲にしている所が多いので、RubyとPythonの仕様の違いで
「Pythonが間違っている！」と指摘するRuby厨はたいてい
視野が狭い。
2009/06/10(水) 21:15:35
>>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の視野が広くなることを願いながら、この話題はここで終了。
2009/06/10(水) 22:00:10
>>526が言語とライブラリの区別もつかない土方な件
2009/06/10(水) 22:04:40
> まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。

ぷ
オブジェクト指向的には"連結せよ"というメッセージは連結子になるオブジェクト(string)に送るのが自然だろ。
ArrayやListに送るという発想はSmalltalkの古いCollectionの設計に縛られているだけ。
2009/06/10(水) 22:08:45
>>526
オブジェクト指向的かどうかではなくて、型に対する態度の問題だと思うぞ。
型を強く意識する言語では、文字列以外も入るリストに要素を文字列として
連結するなんてメソッドを追加するのはあり得ない。

C#のstaticmethod の join は、 Python にも string モジュールに join
という関数がある。文字列に関連したメソッドなんだから str の
インスタンスメソッドにした方が便利だから、インスタンスメソッドに
なっただけ。
2009/06/10(水) 22:13:24
「オブジェクト指向的に自然」って、自分で思いこんでるのが
すべての人にとっても自然だと考えるのはなんでなんだろうね。

少なくとも文字列の連結処理を効率的に行うには文字列の
実装を知らないといけなくて、Arrayが文字列の内部実装を
直接弄って効率的な連結をするのは気持ち悪いな。
2009/06/11(木) 00:45:49
理想の世界で生きていきたくても、
蛇にそそのかされてリンゴを食べたからな。
現実と向き合わないとならないのだよ。
2009/06/11(木) 01:13:38
　　　　　　＿＿＿＿＿_.＿＿＿＿＿_.__
　　　　, '"――――‐, '"――――― ヽ`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
2009/06/11(木) 09:03:24
>>511
>どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。


要素のすべてが文字列である場合じゃないとjoinできないんだから
str/unicode/byteのメソッドなのでは？
534494=502
垢版 |
2009/06/11(木) 13:03:13
>>513
俺は >>498 よりも先に >>494 を書いて、ちゃんと最後まで読んだ上で
RTFM と言ったんだが?
2009/06/11(木) 13:22:39
>>502
違う、全然違う。
str.join は、自動的に unicode へ格上げするような仕様になっている
だけで、実装は + (__add__) よりも効率的なものを使っている。
結果がたまたま等しいだけであって、sep.join([u'a', u'b']) と
u'a' + sep + u'b' は違う意味だ。

「strのjoinだからstr」というのは、逆に言えば「str以外のjoin」は違う動作を
するという意味でもある。

In [3]: k = bytearray('k')
In [4]: k.join([u'a', u'b'])
TypeError: can only join an iterable of bytes (item 0 has type 'unicode')
536535
垢版 |
2009/06/11(木) 13:23:36
>>502 じゃなくて >>511 だった
537デフォルトの名無しさん
垢版 |
2009/06/11(木) 14:57:21
reduce(lambda x,y: str(x) + ',' + str(y), [1,2,3])
これ reduce 使う前提でもっと効率良く書けますか？
2009/06/11(木) 14:58:21
>>> reduce(lambda x,y: x + ',' + str(y), [1,2,3], '')
',1,2,3'
>>> reduce(lambda x,y: x + ',' + y, [1,2,3], '')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <lambda>
TypeError: cannot concatenate 'str' and 'int' objects

ダメぽ orz
2009/06/11(木) 15:00:15
','.join(map(str,[1,2,3]))
2009/06/11(木) 15:34:13
>>539
＞reduce使う前提で

まあその前提条件はどうよという点はさておく
2009/06/11(木) 16:06:04
仮にreduceでどんだけがんばってもjoinよりは速くならないだろう
2009/06/11(木) 16:08:15
reduce(lambda x, y: '%s,%s' % (x, y), [1,2,3])
スマートさを求めるならこのあたりが限界かな
2009/06/11(木) 21:48:41
生成される一時オブジェクトの数のオーダが違うから無理だと思う
2009/06/12(金) 08:08:33
joinは？
2009/06/12(金) 08:17:15
joinを使うと一時オブジェクトなしで計算量O(N)。
reduceを使うと一時オブジェクトがO(N)必要で計算量O(N^2)。
どっちが良いかは明白だな。
2009/06/12(金) 10:16:59
Ruby の join って Enumerable のメソッドでは無くてリストのメソッドなんだな。
Pythonよりよっぽど気持ち悪い。
2009/06/15(月) 06:27:55
123
2009/06/17(水) 12:12:18
daa
2009/06/21(日) 06:52:49
なんかすげーあちこちに飛び火したな、joinネタ
ttp://d.hatena.ne.jp/methane/20090615/1245025996
ttp://blog.livedoor.jp/dankogai/archives/51226075.html
ttp://d.hatena.ne.jp/methane/20090621/1245532793
2009/06/21(日) 12:29:31
>>549
二行目
だんこがい
ってばかだな

class List(list):
    def join(self, j = ''):
        return j.join(map(lambda x: '%s' % x, self))
2009/06/21(日) 12:38:06
return j.join(map(repr, self))
2009/06/21(日) 13:53:50
>>550
>>> t = 'foo',
>>> t
('foo',)
>>> "%s" % t
'foo'
>>> str(t)
"('foo',)"
3行目のmethaneの方がスマート。
でも、 sep.join(x if isinstance(x, basestring) else str(x) for x in iterable) と
一行で書いた方が多分速いな。

>>551
repr と str は違う
2009/07/03(金) 05:29:13

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　 　　　おっぱい！おっぱい！

554デフォルトの名無しさん
垢版 |
2009/07/22(水) 14:57:08
test
2009/07/24(金) 19:32:27
pythonをはじめて使った時に ''.join()みたいな書き方は
あり得ないと思ったけど、慣れてしまえば使いやすいね。
2009/07/24(金) 19:37:07
　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　 　　　おっぱい！おっぱい！
2009/07/25(土) 03:36:26
JavaScriptもjoin使うの知って
まぁそうゆうもんかと思った。
2009/07/25(土) 17:15:15
キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。
559デフォルトの名無しさん
垢版 |
2009/10/03(土) 22:56:53
アンチ少ないお
2009/10/03(土) 23:01:16
　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　 　　　おっぱい！おっぱい！
2009/10/23(金) 03:16:56
Black community in a town of 96% whites. ,
562デフォルトの名無しさん
垢版 |
2009/11/03(火) 20:47:51
インデント記法は慣れれば気にならないし、
xx.lenghがなくてlen(xx)に統一されてるのも
個人的には嫌いだけど一理あるとは認めざる得ない。

でもスライスのx[n:m]の範囲指定は気持ち悪い。
なんか合理的な理由でもあるの？
2009/11/03(火) 20:52:51
他にどんな方法があるの？
2009/11/03(火) 21:37:23
>>562
日本語の勉強してから出直せ
2009/11/03(火) 21:38:46
>>563
[n:m] が n〜(m-1) が気持ち悪いっていう意味だろうと E.S.P.

漏れは合理的だと思うけどね
566デフォルトの名無しさん
垢版 |
2009/11/03(火) 21:47:04
>>565
ああそういう意味か
漏れも>>562が何言ってるのか判らんかった

例えばx文字目からy文字（文字数）取り出すとき
s[x:x+y-1]
とするよりも
s[x:x+y]
の方が計算が少なくて済むし

逆にpythonの中の人も
s[x:y]
が与えられたときに長さが
y-x+1
じゃなくて
y-x
となってここも計算が少なくて済む

小学生でも判るレベルの話
2009/11/03(火) 21:58:48
x文字目からy文字目まで取り出すとき
s[x:y+1]と計算が多くて済むから合理的
568デフォルトの名無しさん
垢版 |
2009/11/03(火) 22:31:58
x文字目から最後の文字からn文字前まで取り出すとき
s[x:-n]と計算が少なくて済むから合理的

>>> 'abcde'[2:]
'cde'
>>> 'abcde'[2:-1]
'cd'
>>> 'abcde'[2:-2]
'c'
569デフォルトの名無しさん
垢版 |
2009/11/03(火) 22:33:52
s = 'abcde'
s[2:len(s)]
s[2:len(s)-1]
s[2:len(s)-2]
2009/11/04(水) 17:09:36
Fortranに倣った
571sage
垢版 |
2009/11/05(木) 01:57:16
>571
a(:)みたいな配列を1-n, n-にわけたいとき、
Fortran a(:n), a(n+1:)
python a[:n] a[n:]
と、pythonの方がすっきりだ。これに気づいてからpythonのスライシングを許せるようになったw
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況