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

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

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

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

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

**デフォルトの名無しさん** · 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ってことかよ。

**507** · 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のメソッドなのでは？

**494=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')

**535** · 2009/06/11(木) 13:23:36

>>502 じゃなくて >>511 だった

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

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

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

キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。

**デフォルトの名無しさん** · 2009/10/03(土) 22:56:53

アンチ少ないお

**デフォルトの名無しさん** · 2009/10/03(土) 23:01:16

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

**TiZCCqJpUPBkUeQHx** · 2009/10/23(金) 03:16:56

Black community in a town of 96% whites. ,

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

漏れは合理的だと思うけどね

**デフォルトの名無しさん** · 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]と計算が多くて済むから合理的

**デフォルトの名無しさん** · 2009/11/03(火) 22:31:58

x文字目から最後の文字からn文字前まで取り出すとき
s[x:-n]と計算が少なくて済むから合理的

>>> 'abcde'[2:]
'cde'
>>> 'abcde'[2:-1]
'cd'
>>> 'abcde'[2:-2]
'c'

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

**sage** · 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

**デフォルトの名無しさん** · 2009/11/05(木) 19:04:13

0-origin の index の場合、 [begin, end) で範囲を表現するのが一般的
大きさ0の範囲を [x,x) で表現できる。

**デフォルトの名無しさん** · 2009/11/06(金) 01:00:35

>>572
その表記ってC++勉強して初めて知ったけど一般的なん？

**デフォルトの名無しさん** · 2009/11/06(金) 01:12:29

数学表記でしょ
閉区間とか開区間とか

**デフォルトの名無しさん** · 2009/11/06(金) 01:36:39

ああそうか、思いっきり一般的だｗ
>>573で初めてとか言ったけど学校で習った覚えもあるわ

**デフォルトの名無しさん** · 2009/11/06(金) 23:36:11

ヨーロッパとかだと半開区間を [a, b[ とか書いたりする

きもい

**デフォルトの名無しさん** · 2009/11/10(火) 17:42:00

http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e
googleは新規のプロジェクトではpythonを使わないように勧めてるらしい

**デフォルトの名無しさん** · 2009/11/10(火) 22:34:32

GAEもう使ってないから関係ないわw

**デフォルトの名無しさん** · 2009/11/11(水) 00:31:02

だからといってRubyやPerlやPHPが代わりに使われることはないわけだが。

**デフォルトの名無しさん** · 2009/11/11(水) 00:33:31

するとGuile？
名前も似てるしな
名前も似てるしな

**デフォルトの名無しさん** · 2009/11/11(水) 01:16:24

Google のいちおしは Noop on Scala だろ

**デフォルトの名無しさん** · 2009/11/11(水) 01:49:35

Javaってことじゃん
やっぱ時代はじゃばだよな！

**デフォルトの名無しさん** · 2009/11/11(水) 12:50:13

Goって囲碁のプログラムかと思ったよ

シンプルで高速、Googleの新プログラミング言語「Go」
ttp://journal.mycom.co.jp/news/2009/11/11/025/?rt=na

**デフォルトの名無しさん** · 2009/11/11(水) 15:23:00

Google の中の人、言語作るの好きだな

**デフォルトの名無しさん** · 2009/11/11(水) 18:21:08

Noopが当て馬、Goが本命？

**デフォルトの名無しさん** · 2009/11/11(水) 22:10:10

また中途半端なものを出してきたなw

**デフォルトの名無しさん** · 2009/11/11(水) 22:46:39

単に Google の中の人は飽きっぽいだけだと思

**デフォルトの名無しさん** · 2009/12/25(金) 20:18:30

test

**デフォルトの名無しさん** · 2010/01/10(日) 22:59:29

なんでlist.rindexがないのか、理解できない

**デフォルトの名無しさん** · 2010/01/10(日) 23:03:05

双方向リンクになってないから？
reverseかけてからやるしかないね

**デフォルトの名無しさん** · 2010/04/10(土) 18:43:33

なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。