Pythonのお勉強 Part37

1 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 16:59:28 ] Pythonオフィシャルサイト www.python.org/ 日本Pythonユーザ会 www.python.jp/Zope/ まとめWiki python.rdy.jp/ 関連スレ find.2ch.net/?BBS=ALL&TYPE=TITLE&STR=python 前スレ pc12.2ch.net/test/read.cgi/tech/1264924208/ 96 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 10:32:23 ] >>95 「普通はユーザーが使う物じゃないから」なんて理由で、一部の例外オブジェクトを catchできるけどraiseできないみたいなヘンな制限を付けてないだけだろうな。 raise KeyboardInterrupt だろうがなんだろうができるけど、普通はしない。 普通じゃない場合としては、プラグインシステムのあるアプリで、プラグインに SyntaxErrorが起こるようなスクリプトをぶち込まれた場合をテストするために あえてraiseするとかかなぁ。 97 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 10:55:51 ] >>90 「気持ち悪い」理由が俺にはさっぱりわからん 単に、エラーを含む可能性のあるPythonコードを実行時に解釈したいのなら eval・compile系が使えるけど >>92 多重ループどころか、列挙の停止はいつもStopIteration例外じゃないか 98 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 11:34:51 ] >>97 こういうことだろ。 class TajuuloopNukeru(Exception): 　　pass try: 　　for i in someiter: 　　　　for j in someiter2: 　　　　　　if somecond: 　　　　　　　　raise TajuuloopNukeru # ここで一気にループを抜けるために例外を投げる except TajuuloopNukeru: 　　pass 99 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 11:39:59 ] >>98 いや文意は分かってるよ 別に多重じゃなくてもどうせ列挙の脱出にはいつもStopIterationが使われてるんだから 好きにすれば？ってこと 100 名前：デフォルトの名無しさん [2010/03/16(火) 11:48:04 ] 例外はgotoの代わりに仕えって死んだじいちゃんが言ってた 101 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 12:15:10 ] イテレータの中で要素を動的にパースするときとか 自分用の小さいスクリプトだったら例外で抜けちゃうな まあ、先にリスト作っとけって話なんだけど、楽なんで 102 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 12:35:31 ] 先にリストを作ると、長大に要素を含む可能性のあるイテレータの処理が重くなったりすると思うんだ。 103 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 13:11:30 ] 多重ループならそれこそジェネレータ使えよ 104 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 13:14:06 ] と言ってはみたがイテレータの中でraise StopIteration使っても同じことだな よく読んでなかった 105 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 17:23:38 ] 例外やgotoはpythonに限った話じゃないと思うんだが その辺現状のマジョリティとしてはどういう見解なの？ なんか昔はgotoに拒絶反応示す人がいたように思うんだが 106 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 17:29:20 ] It is Easier to Ask for Forgiveness than Permission. 107 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 21:34:05 ] intのparseの例は、.NETのNullable型や関数型のOption型みたいなものがあれば それで返せば、という気がしなくもない 例外やgoto云々は完全に言語によるのでは 少なくとも非常に手続き的だとは言える C++界隈だと、別の理由で例外を過度に多用するなというコンセンサスがある気がする 108 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 23:26:33 ] 辞書のgetにもdefaultがあるんだからデフォルト値指定ができてもいいと思うけどなー あとoption型なんかは動的型ならNone返せばいいだけなので問題はそこじゃないと思う 109 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:02:56 ] >>108 int() に default をつけてしまうと、こんどは例外を投げられなくなってしまう。 例えば、defaultのデフォルト値がNoneだとすると、「int()に変換できるハズ」と 思い込んで返り値チェックを省略すると数値オブジェクトを期待している場所に Noneが入った状態で、その後のどこかでエラーが起こるか何かを壊してしまう。 例外なら、「ハズ」の思い込みと違うことが起こっても帯域脱出してくれるので、 「ハズ」の部分でチェックを省略できる。 辞書に [] と .get() があるように、int()と別の関数として用意するのはアリ。 アリだから、 >>51みたいな関数を用意すれば良い。 組み込み名前空間を汚してまで組み込む必要が認められなかったので 組み込み関数にはなって無いだけ。 110 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:12:17 ] int(hoge, default=None) ができれば・・・ try: 　　fuga = int(hoge) catch: 　　〜〜 が fuga = int(hoge, default=None) if fuga is None: 　　〜〜 3行になる！ ああ、石を投げないで！ 111 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:34:46 ] じゃなくて、 try: 　　fuga = int(hoge) catch: 　　fuga = 0 を考えてる時に例外使うのは素直じゃないだろということだろ 112 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:37:42 ] 一瞬pythonスレじゃないのかとおもった 113 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:42:44 ] >>110 単にデフォルトで潰したいときも、パース不能のときも、それで済むなあ まあこういうのはユーティリティ関数を自分で書けば事足りる程度の話ではあるが 114 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:45:42 ] >>111 それが素直じゃないと思うなら、まずその幻想を打ち壊す！ いや、「素直じゃない」なんてなんの根拠もない個人的感想は 全く気にしない言語だから。 例外投げる方がシンプルで、例外投げない方を別に用意しても 大して利益がないのであれば、例外なげない関数なんて用意しないよ。 >>110 int() はただの関数じゃなくて型だから、Noneを返すなんて仕様は有り得ない。 default を追加するなら int と別の関数を用意する必要がある。 でも、組み込み関数をその程度の要望では増やさない。 115 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:47:45 ] >>113 だから、>>109で言っているように、 fuga = int(hoge) の一行が fuga = int(hoge, default=None) if fuga is None:     raise ValueError("hoge is not integer") の3行に増えるんだって。 116 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:55:44 ] default の初期値は「未指定」でいいじゃない。 PyArg_ParseTupleAndKeywords()の書き方次第でNoneではない「未指定」のデフォルトにできるじゃんね。 int('abc') → ValurError int('abc', 16) → 2748 int('abc', default=None) → None 117 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:13:30 ] >>116 「未指定」なんてオブジェクトはない あと、>>114で言っているように int() が None を返しちゃダメ。 intかintと上位互換のlongを返さないと。 118 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:22:55 ] >>117 そういうオブジェクトはないけど、 def to_int(val, **kwargs): 　if 'default' in kwargs: 　　pass みたいな処理はできるってことを言いたいんじゃないかなぁ。 intがint以外のインスタンス返す仕様になってほしいとはまったくもって思わんけど。 119 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:34:12 ] ビルドインを増やすのが嫌なら int.parse(string)ってスタティックメソッドを作ればいいんじゃないかな 120 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:47:14 ] >>117 それだと、今度は (val [, base [, default]]) という順序引数が使えなくなるね。 intが例外を投げる関数としてあるんだから、int以外の関数を使うなら defaultは普通にNoneがデフォルト値の引数で良いんだよ。 問題は、大して利点無くビルトインを増やすこと。 >>119 うん、どうしてもdefaultが欲しいなら、それが一番Pythonicだね。 残る問題は、今のところ組み込み型にはstaticmethodが無いという事だけだ。 int.parseのためだけに組み込み型のstaticmethodを用意するのはやっぱり 無いだろうけど、他にも組み込み型staticmethodの要求が増えてきたら ついでに int.parse が入るかも。 121 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 06:21:49 ] def int(s, exception=True, default=0): みたいに定義しといて exception=False で使ったときだけdefaultを返せば良いと思う 122 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 09:33:17 ] 型の変換はバリデータとかでさっくりやるんじゃねえの？ typeにstaticmethod追加するとかバカか？ 123 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:18:34 ] >>122 えっ 124 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:24:44 ] >>122 元の要求は明らかに unicode(s, 'utf-8', errors='ignore') あたりからの類推だろうし、別にそんなに変な話じゃないと思うが 125 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:32:41 ] 別ディレクトリにある.pyファイルをimportしたい時って、sys.pathを直接いじるのが一般的なの？ 126 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:38:56 ] メインプログラムのサブディレクトリに配置すれば良いじゃん 127 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 11:03:58 ] __import__() を使おう 128 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:36:00 ] >>124 たしかにunicodeはencodingやerrrosを指定できるけど戻り値は必ずunicode型だろ int(hoge, default=None)みたいにint以外返せるのはおかしい 129 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:36:50 ] おいおい、まだやってたのか 130 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:41:03 ] unicode のつもりが None が入ってるときはあるし str のつもりが None が入ってるときもある int のつもりの変数に None が入ってても何もおかしなことではない そもそも型宣言がないんだから 131 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:46:14 ] >>130 変数側の問題じゃなくて、int()の戻り値の問題。 int や str みたいな型は関数形式で呼び出してインスタンスを作るけど、 assert isinstance(sometype(), sometype) という暗黙の了解があるの。 引数が悪くてその型の値を返せないときは例外を投げるべき。 132 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:48:40 ] sqlite3 とかでレコード取り出したときに str だと思ってたのに None が入ってるときがあるね 133 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:49:47 ] sがstrだとして s.decode('utf-8') みたいな使い方をしてるときに sがNoneで例外出ると萎える 134 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 13:35:54 ] 上では int(s) -> parseできなければ例外 int(s, base) -> 同じ int(s, default=...) -> parseできなければdefaultを返す int(s, base, default=...) -> 同じ こういう感じの話をしてたんだと思うが default=を指定しなければ今と全く同じだし parse不能なケースはデフォルト値で置き換えでいい場合は try/exceptを含む4行程度のコードが式一つ圧縮できるわけだろ default=Noneと「わざわざ」指定してNoneが返った場合の対応を「しない」のは さすがに考えにくいんじゃないの 135 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 13:43:13 ] >>134 だから、int()にint以外のオブジェクトを返させるなって。 136 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:03:13 ] というか可能性としてはint.parseの方がよっぽど高いだろうに コンストラクタでやろうとするほうが議論の中心になるのが納得できない まぁ意固地なヤツのせいで議論にすらなってないわけだが 137 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:11:10 ] 本家フォーラムで話さない時点で可能性の話をしても意味ないと思うの 138 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:34:45 ] 別に正直どうでもいいが つまり>>134がint()じゃなくてint.parse()でなければ特にケチをつける 理由は無いということ？ 139 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:35:28 ] ×int.parse()でなければ ○int.parse()であれば 140 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:49:34 ] >>138-139 int()と別にint.parse()を用意するのであれば、今度は例外を投げる必要がなくて、 default=0かdefault=Noneで良い。 というのが >>120 に既出 141 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:58:20 ] なるほど 142 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 21:11:41 ] 誰か話まとめて 143 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 21:29:45 ] Ruby最高 144 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 22:22:10 ] int.parse() は int がオブジェクトじゃないからクラスメソッドが使えないって話 >>134 なら ちゃんと >default=Noneと「わざわざ」指定してNoneが返った場合の対応を「しない」のは >さすがに考えにくいんじゃないの と断ってあるので >>135 みたいな突っ込みをする香具師はただのKYアホだと思う 145 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 22:23:30 ] >>134 最高 146 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 23:08:43 ] parse_intでも自作しろよ 147 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 23:13:10 ] 仮にintにdefualtがある場合、defaultの型がint,longでないときに例外出せばいい 148 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 01:52:28 ] 結局今の仕様通り、例外処理が一番スマートってことかな？ 149 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 01:53:55 ] int()が関数でなく型(のコンストラクタ?)だってのは理解してるので、 必ずしも int を拡張しなくてもよいんだけど、 Battery includedを唱うPythonで、プロジェクト起こすたびに 同じ関数を作ってるのがちょっぴりイヤ。 どこか適当なモジュールに xint() とか parseInt() とか入れてくれないかな。 150 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:08:03 ] >>149 そんな頻繁にparseInt使いたくなるか？ intに直せないかもしれない未知の文字列をintにしたいときってどういう場合だ？ 直せなかったときの対処は0入れるとか、None入れるとかで本当に適切なのか？ その場でエラー出した方がいいんじゃないの？ 151 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:13:29 ] 大抵の場合は n = int(s) if isdigit(s) else None で十分。符号とか前後スペースとか考えると面倒くさくなるが。 152 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:44:49 ] なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな 周囲の環境を否定することでしか自我を保てない哀れな野郎だ 153 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 03:29:35 ] 珍しくPythonスレが伸びてるからみんな暇つぶしで付き合ってるんじゃないの 154 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 03:58:42 ] >>152 愚痴しか言えないお前もなw 155 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 09:21:21 ] イベントにしか興味がなくて仕事をしない不思議な動物を飼っておく余裕はなくなったのだよ。 156 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 09:26:36 ] がんばれアイちゃん 157 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 09:31:32 ] 292 デフォルトの名無しさん [sage] 2010/03/18(木) 07:15:50 ID: Be:     なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな     周囲の環境を否定することでしか自我を保てない哀れな野郎だ 293 デフォルトの名無しさん [sage] 2010/03/18(木) 09:29:56 ID: Be:     ＞C#は糞     ＞pc12.2ch.net/test/read.cgi/tech/1246520657/l50     ＞711 名前： デフォルトの名無しさん [sage] 投稿日： 2010/03/18(木) 02:50:41     ＞なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな     ＞周囲の環境を否定することでしか自我を保てない哀れな野郎だ     ＞C#終了のお知らせ     ＞pc12.2ch.net/test/read.cgi/tech/1200796178/l50     ＞292 名前： デフォルトの名無しさん [sage] 投稿日： 2010/03/18(木) 07:15:50     ＞なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな     ＞周囲の環境を否定することでしか自我を保てない哀れな野郎だ     ｗｗｗ 158 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 10:12:26 ] >>149 予めあったらいいね。chomp とかもね 159 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 10:20:55 ] rstrip 160 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:00:20 ] >>159 いちいち rstrip("\r\n") と書くのがめんどい 161 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:17:55 ] じゃあ外出て彼女でも作れよ 162 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:20:17 ] >>160 てめぇPerlに喧嘩売ってんのか 163 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:23:11 ] >>160 改行は削除したいがtrailing spaceは保存したいケースってそんなに多いかなあ 164 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:33:02 ] ほんの数タイプ削減するためだけに、 parseInt や chomp を別に用意する必要は無い。 165 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:51:08 ] >>151 つまり、符号や前後スペースの問題等を考慮すれば、結局 def int_parsable(s): 　try: 　　int(s) 　　return True 　except: 　　return False のような馬鹿馬鹿しいものを書くことになるわけでしょ 現実のプログラムで ValueError: invalid literal for int() with base 10: .... が最適なエラーメッセージだと考える人はいないだろうし 自分しか使わないオモチャをのぞけば、デフォルトの例外投げっぱなしが 最適解であることはむしろ稀なんじゃないの 166 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:59:17 ] わらた 167 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:02:23 ] >>165 そんなばかばかしい関数書かないよ。 ユーザーが入力した文字列を利用するなら、 try:     x = int(s) except Exception:     # ユーザーにメッセージを表示 # x を使った処理 で十分。 >>151みたいな書き方をすることはない。 168 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:06:39 ] >>167 try〜exceptを含む4つの文より、一つの式のほうが簡潔な上に、 抽象化された構造に取り込みやすいこともあるんじゃないの >>151の右辺は式だからね ああ書きたければ、isdigit()では不十分なので int_parsable()が必要になる、ということ 169 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:08:28 ] これが日本のレベル 170 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:09:25 ] >>153 それもこれも、みんな俺の努力の賜でね 171 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:10:04 ] 下手な回復されるよりは例外出される方がマシじゃん 172 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:11:27 ] そして ValueError: invalid literal for int() with base 10: .... を印字して終了するわけか 173 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:32:04 ] >>168 >>151みたいに書いたって、その後で if n is None:     # ユーザーにまともなエラーメッセージを表示 ってやったら三行じゃん。 >>165でエンドユーザーに対してエラーメッセージを表示することについて 言っているけど、Noneなんて入れっぱなしにしたら TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' みたいなエラーがその後のどっか別の場所で出て、エンドユーザーにとって判りにくいどころか プログラマにとってもいつint以外のオブジェクトが入ったのか探す必要が発生するわけだが。 174 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:36:33 ] >>173 int_parsable()では、デフォルト値でいい場合に n = int(s) if int_parsable(s) else default で済み、明らかに少ないし、 Value Error以外の、もっと有用なメッセージを出力したい場合も if not int_parsable(s): raise ほげException(有用なメッセージ) の1行で済むよ 175 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:38:20 ] つまり、防御的に書かない書き捨てコードの ... n = int(s) ... に対して、 ... if not int_parsable(s): .... n = int(s) ... と一行はさむだけで防御的になるわけだ 176 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:52:46 ] 仕事しろよこの穀潰しが 177 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:54:36 ] >>174 デフォルト値で良い場合は >>51 で良いし、 例外メッセージを書き換えたい場合は def int_parse(s, msg):     try:         return int(s)     except Exception:         raise HogeException(msg) とした方が良いな。 このあたりはアプリケーション毎に違うんだから自分で書いたらいい。 178 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 14:31:51 ] 春休みになるとここまで雰囲気が変わるのかよ 179 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 14:34:58 ] 社内ニートも加わってさらにひどいことに． 180 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:26:30 ] つーか、まだやってたのか 181 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:40:43 ] 質問です。 Pythonのコマンドラインを起動して、「3+4」と入力すると「7」が帰って来ます。 この「7」って__doc__とか__name__のどこかに格納されているのでしょうか？ また、「7」の型を判定することは可能でしょうか？ 182 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:44:04 ] 何が聞きたいのかさっぱりわからん $ python Python 2.6.4 (r264:75706, Jan 25 2010, 09:01:01) [GCC 4.4.2 20091208 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3+4 7 >>> _ 7 >>> type(_) <type 'int'> >>> 183 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:50:08 ] #型の判定 isinstance(7,int) True isinstance("7",int) False #数値型に変換できるかの判定 "7".isdigit() True "'7'".isdigit() False 184 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:08:33 ] >>182-183 「_」と「typeやisinstance」がまさに知りたかった情報です。 ありがとうございます。 でも不思議なのですが、dir()しても「_」というオブジェクトは見つかりません。 「_」の情報はどこに定義されているのでしょうか？ 185 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:15:47 ] __builtins__._ 186 名前：181 mailto:sage [2010/03/18(木) 16:28:45 ] >>185 納得しました。 ありがとうございます。 187 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:45:25 ] この春厨は同じ春厨でも筋のいい春厨だから仲良くな。 188 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:05:51 ] 皆さんいかがお過ごしでしょうか。 ストレス解消に煽りに来ている方、十分な睡眠を取って煽ってくださるようお願い申し上げます。 風邪を引く前の予防が肝心です。日々の鍛錬を怠らないようにして下さい。 暇つぶしに来ている方、時間を決めて一時間ごとに十五分から二十分くらいの休息を取られた方が良いと思います。 時間は限られています。あなたの人生はあなたの物ですが、一日中インターネットに没頭している、これはいかがな物でしょうか。 インターネットはあなた様の健康に悪影響を及ぼす可能性があります。 マルチしている方、人を忘れないでください、すべてはたくさんの人の多大な努力と膨大な時間を費やして出来た物でありますが故に、 そのような行為は非人道的行為にあたります。なお九十割はスクリプトで出来ているので、気軽に質問してください。マルチはいけません。 さて、私がこのような事をなぜ申し上げますかというと、この度Goのビルドに成功したが故に存じ上げる次第でございます。 よくよく冷静に考えると、このような開発段階にあり、現段階では実用に適していない「ぼくのかんがえたさいきょうのげんご」は プログラミング言語の学習に適さないと判断させていただきました。今後ますますのご健康とご活躍をお祈り申し上げます。 189 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:27:07 ] 長文は縦読みかどうかしか確認しないのが俺のジャスティス（キリ 190 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 19:15:58 ] >>188 特定しました 191 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:08:19 ] >>175 それ、1行挟むだけで済ませようと思ったらreturnかexitくらいしか入らないんじゃない？ 192 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:09:15 ] >>191 raiseもいれられるお！ 193 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:15:19 ] ってかマジレスすると、 その1行が想定している意味は、すぐ上の>>174を読めば分かる 194 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:16:55 ] なんてかpersable()がないのは、変換する必要がない場面で変換可能かを調べる必要が滅多にないこと、 変換する必要がある場面で例外にしてはいけない合理的理由が特に見当たらないこと、その2点に集約されてる気がする。 (Python 195 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:23:01 ] 途中で書き込んでしまった。すまそ (pythonでは例外使うことに抵抗がなく、むしろ積極的に使っている節がある。 それに、何もかもを1行で書きたいという欲求に、Guideは全然興味を示してない。 多分、三項演算子ができたのも、論理演算子を組み合わせた直感的でない方法取られるよりはマシとの判断) str.indexとstr.findが両方あることを考えるに、 intが例外を返すのが直感的でない、例外を返さないことに意義がある場面が十分ありうるのなら、 既にparse_intは取り入れられてるはずだろう。 196 名前：デフォルトの名無しさん mailto:sage [2010/03/19(金) 01:08:04 ] >>195 strにfindとindexの2種類合ってintには無い理由の大きな理由は、 str.find と str.index が メソッドなのに対して str は組み込み型だからだと思うよ。

---

---

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

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