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

1 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 10:24:06 .net] Pythonが嫌いな人のためのスレッドです。 ■関連スレ Rubyについて（アンチ専用） Part002 pc11.2ch.net/test/read.cgi/tech/1200210768/ 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 と言ったんだが? 535 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 13:22:39 .net] >>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') 536 名前：535 mailto:sage [2009/06/11(木) 13:23:36 .net] >>502 じゃなくて >>511 だった 537 名前：デフォルトの名無しさん [2009/06/11(木) 14:57:21 .net] reduce(lambda x,y: str(x) + ',' + str(y), [1,2,3]) これ reduce 使う前提でもっと効率良く書けますか？ 538 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 14:58:21 .net] >>> 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 539 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 15:00:15 .net] ','.join(map(str,[1,2,3])) 540 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 15:34:13 .net] >>539 ＞reduce使う前提で まあその前提条件はどうよという点はさておく 541 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 16:06:04 .net] 仮にreduceでどんだけがんばってもjoinよりは速くならないだろう 542 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 16:08:15 .net] reduce(lambda x, y: '%s,%s' % (x, y), [1,2,3]) スマートさを求めるならこのあたりが限界かな 543 名前：デフォルトの名無しさん mailto:sage [2009/06/11(木) 21:48:41 .net] 生成される一時オブジェクトの数のオーダが違うから無理だと思う 544 名前：デフォルトの名無しさん mailto:sage [2009/06/12(金) 08:08:33 .net] joinは？ 545 名前：デフォルトの名無しさん mailto:sage [2009/06/12(金) 08:17:15 .net] joinを使うと一時オブジェクトなしで計算量O(N)。 reduceを使うと一時オブジェクトがO(N)必要で計算量O(N^2)。 どっちが良いかは明白だな。 546 名前：デフォルトの名無しさん mailto:sage [2009/06/12(金) 10:16:59 .net] Ruby の join って Enumerable のメソッドでは無くてリストのメソッドなんだな。 Pythonよりよっぽど気持ち悪い。 547 名前：デフォルトの名無しさん mailto:sage [2009/06/15(月) 06:27:55 .net] 123 548 名前：デフォルトの名無しさん mailto:sage [2009/06/17(水) 12:12:18 .net] daa 549 名前：デフォルトの名無しさん mailto:sage [2009/06/21(日) 06:52:49 .net] なんかすげーあちこちに飛び火したな、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 550 名前：デフォルトの名無しさん mailto:sage [2009/06/21(日) 12:29:31 .net] >>549 二行目 だんこがい ってばかだな class List(list):     def join(self, j = ''):         return j.join(map(lambda x: '%s' % x, self)) 551 名前：デフォルトの名無しさん mailto:sage [2009/06/21(日) 12:38:06 .net] return j.join(map(repr, self)) 552 名前：デフォルトの名無しさん mailto:sage [2009/06/21(日) 13:53:50 .net] >>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 は違う 553 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 05:29:13 .net] 　　　 ┌─┐ 　　　 │●│ 　　　 └─┤ 　　　_ 　 ∩ 　　( ﾟ∀ﾟ)彡 ┌─┬⊂彡 │●│　おっぱい！おっぱい！ └─┘　　 　　　おっぱい！おっぱい！ 554 名前：デフォルトの名無しさん [2009/07/22(水) 14:57:08 .net] test 555 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 19:32:27 .net] pythonをはじめて使った時に ''.join()みたいな書き方は あり得ないと思ったけど、慣れてしまえば使いやすいね。 556 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 19:37:07 .net] 　　　 ┌─┐ 　　　 │●│ 　　　 └─┤ 　　　_ 　 ∩ 　　( ﾟ∀ﾟ)彡 ┌─┬⊂彡 │●│　おっぱい！おっぱい！ └─┘　　 　　　おっぱい！おっぱい！ 557 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 03:36:26 .net] JavaScriptもjoin使うの知って まぁそうゆうもんかと思った。 558 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 17:15:15 .net] キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。 559 名前：デフォルトの名無しさん [2009/10/03(土) 22:56:53 .net] アンチ少ないお 560 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 23:01:16 .net] 　　　 ┌─┐ 　　　 │●│ 　　　 └─┤ 　　　_ 　 ∩ 　　( ﾟ∀ﾟ)彡 ┌─┬⊂彡 │●│　おっぱい！おっぱい！ └─┘　　 　　　おっぱい！おっぱい！ 561 名前：TiZCCqJpUPBkUeQHx mailto:6l8b8n21.@gmail.com [2009/10/23(金) 03:16:56 .net] Black community in a town of 96% whites. , 562 名前：デフォルトの名無しさん [2009/11/03(火) 20:47:51 .net] インデント記法は慣れれば気にならないし、 xx.lenghがなくてlen(xx)に統一されてるのも 個人的には嫌いだけど一理あるとは認めざる得ない。 でもスライスのx[n:m]の範囲指定は気持ち悪い。 なんか合理的な理由でもあるの？ 563 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 20:52:51 .net] 他にどんな方法があるの？ 564 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 21:37:23 .net] >>562 日本語の勉強してから出直せ 565 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 21:38:46 .net] >>563 [n:m] が n〜(m-1) が気持ち悪いっていう意味だろうと E.S.P. 漏れは合理的だと思うけどね 566 名前：デフォルトの名無しさん [2009/11/03(火) 21:47:04 .net] >>565 ああそういう意味か 漏れも>>562が何言ってるのか判らんかった 例えばx文字目からy文字（文字数）取り出すとき s[x:x+y-1] とするよりも s[x:x+y] の方が計算が少なくて済むし 逆にpythonの中の人も s[x:y] が与えられたときに長さが y-x+1 じゃなくて y-x となってここも計算が少なくて済む 小学生でも判るレベルの話 567 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 21:58:48 .net] x文字目からy文字目まで取り出すとき s[x:y+1]と計算が多くて済むから合理的 568 名前：デフォルトの名無しさん [2009/11/03(火) 22:31:58 .net] x文字目から最後の文字からn文字前まで取り出すとき s[x:-n]と計算が少なくて済むから合理的 >>> 'abcde'[2:] 'cde' >>> 'abcde'[2:-1] 'cd' >>> 'abcde'[2:-2] 'c' 569 名前：デフォルトの名無しさん [2009/11/03(火) 22:33:52 .net] s = 'abcde' s[2:len(s)] s[2:len(s)-1] s[2:len(s)-2] 570 名前：デフォルトの名無しさん mailto:sage [2009/11/04(水) 17:09:36 .net] Fortranに倣った 571 名前：sage [2009/11/05(木) 01:57:16 .net] >571 a(:)みたいな配列を1-n, n-にわけたいとき、 Fortran a(:n), a(n+1:) python a[:n] a[n:] と、pythonの方がすっきりだ。これに気づいてからpythonのスライシングを許せるようになったw 572 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 19:04:13 .net] 0-origin の index の場合、 [begin, end) で範囲を表現するのが一般的 大きさ0の範囲を [x,x) で表現できる。 573 名前：デフォルトの名無しさん mailto:sage [2009/11/06(金) 01:00:35 .net] >>572 その表記ってC++勉強して初めて知ったけど一般的なん？ 574 名前：デフォルトの名無しさん mailto:sage [2009/11/06(金) 01:12:29 .net] 数学表記でしょ 閉区間とか開区間とか 575 名前：デフォルトの名無しさん mailto:sage [2009/11/06(金) 01:36:39 .net] ああそうか、思いっきり一般的だｗ >>573で初めてとか言ったけど学校で習った覚えもあるわ 576 名前：デフォルトの名無しさん mailto:sage [2009/11/06(金) 23:36:11 .net] ヨーロッパとかだと半開区間を [a, b[ とか書いたりする きもい 577 名前：デフォルトの名無しさん mailto:sage [2009/11/10(火) 17:42:00 .net] groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e googleは新規のプロジェクトではpythonを使わないように勧めてるらしい 578 名前：デフォルトの名無しさん mailto:sage [2009/11/10(火) 22:34:32 .net] GAEもう使ってないから関係ないわw 579 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 00:31:02 .net] だからといってRubyやPerlやPHPが代わりに使われることはないわけだが。 580 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 00:33:31 .net] するとGuile？ 名前も似てるしな 名前も似てるしな 581 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 01:16:24 .net] Google のいちおしは Noop on Scala だろ 582 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 01:49:35 .net] Javaってことじゃん やっぱ時代はじゃばだよな！ 583 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 12:50:13 .net] Goって囲碁のプログラムかと思ったよ シンプルで高速、Googleの新プログラミング言語「Go」 ttp://journal.mycom.co.jp/news/2009/11/11/025/?rt=na 584 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 15:23:00 .net] Google の中の人、言語作るの好きだな 585 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 18:21:08 .net] Noopが当て馬、Goが本命？ 586 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 22:10:10 .net] また中途半端なものを出してきたなw 587 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 22:46:39 .net] 単に Google の中の人は飽きっぽいだけだと思 588 名前：デフォルトの名無しさん mailto:sage [2009/12/25(金) 20:18:30 .net] test 589 名前：デフォルトの名無しさん mailto:sage [2010/01/10(日) 22:59:29 .net] なんでlist.rindexがないのか、理解できない 590 名前：デフォルトの名無しさん mailto:sage [2010/01/10(日) 23:03:05 .net] 双方向リンクになってないから？ reverseかけてからやるしかないね 591 名前：デフォルトの名無しさん mailto:sage [2010/04/10(土) 18:43:33 .net] なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。 592 名前：デフォルトの名無しさん mailto:sage [2010/04/11(日) 16:53:40 .net] このスレが機能してないからでは 593 名前：デフォルトの名無しさん mailto:sage [2010/04/11(日) 17:28:44 .net] ここはスレタイがネガティブだから平和なのでは。 本スレに"人生の敗北者でも使える"を付けてみるとか。 594 名前：デフォルトの名無しさん mailto:sage [2010/04/11(日) 18:38:07 .net] そういえば昔は付いてたな 595 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 13:15:53 .net] とあるエディットボックスの日本語入力中にIMEの変換中の文字列を取得したいのですが from ctypes import * from ctypes.wintypes import * ImmGetContext = windll.imm32.ImmGetContext ImmGetContext.argtypes = [c_int] ImmGetContext.restypes = c_int ImmGetCompositionString = windll.imm32.ImmGetCompositionStringA ImmGetCompositionString.argtypes = [c_int, c_int, c_char_p, c_int] ImmGetCompositionString.restypes = c_int GCS_COMPSTR = 0x0008 hwnd = エディットボックスのウインドウハンドル himc = ImmGetContext(hwnd) # 入力コンテキスト取得 buf = create_string_buffer('dummy', 1024) # バッファ作成 print ImmGetCompositionString(himc, GCS_COMPSTR, buf, 0) # IME変換中の文字列の長さに応じた値が返ってくる print ' '.join(('%02x' % ord(c)) for c in buf.raw) # 常にバッファ作成時の初期化文字列「'dummy'」しか返ってこない …となってしまいます ctypes のポインタ渡しの説明を見ると c_char_p ではなく create_string_buffer で作ったものを渡せとあるので そうしたつもりなのですが期待通りに動きません どなたか上手く取得する方法を教えてください ちなみに buf = create_string_buffer('dummy', 1024) print '>', # libc.scanf('%s', buf) cdll.msvcrt.scanf('%s', buf) print ' '.join(('%02x' % ord(c)) for c in buf.raw) print buf.value こちらは動きます バッファオーバーランとかの突っ込みはなしでおながいします 596 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 14:16:47 .net] ImmGetCompositionString(himc, GCS_COMPSTR, byref(buf), 0) は？ 597 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 14:54:02 .net] ImmGetCompositionStringの第4引数を0 => len(buf)あるいは1024 598 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 14:55:20 .net] ImmGetCompositionStringの 3つ目の引数はLPVOIDだけど char*として扱っていいのか？ 599 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 15:01:11 .net] >>596-598 ありがとうございます ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf.raw)) で取得出来ました 600 名前：デフォルトの名無しさん mailto:sage [2010/04/14(水) 15:10:26 .net] なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。

---

---

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

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