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/ 44 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:14:44 ] >>33 default=0 は判るけど、 errors='ignore' したらその関数の結果はどうなるの？ 「実行して例外出たら」というのは、基本的にそういうポリシーでやってる。 なんでそんなポリシーなのかというと、 1. 先行チェック関数と実行関数の二つが必要になると、それだけ要素が増える 2. 先行チェックの関数を用意しても、実行用関数でチェックが不要になるわけではない。 3. 先行チェックだけが必要になる場合はあんまりない。 if int.tryparse(s):  x = int(s) else:  x = 0 と書くのと、 try:  x = int(s) except ValueError:  x = 0 と書くのと比べて、別に格好悪い事なんてなんにもないし。 45 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:25:47 ] x = int(s) if int.tryparse(s) else 0 46 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:38:01 ] >>45 tryparseなのに真偽しか返さないのはおかしくないか 47 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:40:54 ] >>44だった... 48 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:42:25 ] >>45 確かに、3項演算子が使えるのは便利だね。 でも、そのためだけに int.tryparse() を実装するのはやり過ぎ。 try文も3項演算子作ろうよっていう話が少し前に Python-dev や Python-idea で 流れたけど、例外のタイプを複数利用したい場合とか、汎用的に使える物を きれいな構文にするのが難しくてまとまらなかった模様。 複数の文字列に対して繰り返し実行する必要がある場合は、その場合に応じて 関数作れば良いしね。手軽に関数を作れるのがPythonの良いところなんだから。 def toint(s, default=0): try: return int(s) except Exception: return default x = toint(a) y = toint(b, 1) z = toint(c) 49 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:43:58 ] >>47 あー、名前をC#から拝借したんだけど、checkparsable()の方が好み？ 真偽を返すのは、 if int.tryparse("0") が偽にならないため。 50 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:46:57 ] >>48 ありがとうございました 51 名前：48 mailto:sage [2010/03/14(日) 14:54:08 ] あー、 try-except の部分、一行じゃ書けなかった。3行必要だ。 def toint(s, default=0):     try: return int(s)     except Exception: return default 52 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 14:55:36 ] >>43 Python3.1だとintの方もエラーになるけど、2.6だとならない 53 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:10:11 ] >>48 またコンビニ野郎かよ そういう奴が居るからPythonは低速って言われるんだよ 54 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:11:09 ] そろそろ2.6にアップグレードしてもよかと？ 55 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:15:50 ] せんとすはいつまで2.4なのかねぇ 56 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:17:48 ] >>53 こーゆー作業をしている部分はユーザーの入力チェックとか 設定ファイルの読み込みとかボトルネックじゃない事がほとんどだから 実行時間を気にする必要ないよね？ Pythonは低速とか、誰が非難してるの？ 速度が必要な部分は拡張モジュール書けばいいんだし、 ボトルネック以外の部分が多少遅くても問題ない。 57 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:20:36 ] 話は変わるけど、Pythonはほんとに低速 58 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:22:19 ] >>56 >速度が必要な部分は拡張モジュール書けばいいんだし、 >ボトルネック以外の部分が多少遅くても問題ない。 今時は動的言語も仮想マシンと実行時コンパイルが当たり前になって来たからな。 メソッド呼び出しとか真偽判定みたいな内部機能は拡張じゃどうしようもないし。 59 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:48:45 ] まだやってたのか 60 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 19:18:59 ] せんとすは2.6にアップグレードしてもよか 61 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 19:43:03 ] する意味ないからしないんだろう。 必要なら/usr/localに入れればいい。 62 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 20:23:14 ] CentOS の新しいメジャーバージョンが早く出てくれないと、いろんな主要ライブラリで Python 2.4 のサポートを切る動きが出てこない。 有名なライブラリにテスト済みのパッチを送るためにローカルにPython 2.4, 2.5, 2.6, 3.1, trunk, py3k を全部入れるのは面倒だ。 63 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 21:06:50 ] OSの根幹にかかわる部分をpythonで書くのは不安だ perlじゃなぜダメなんだ 64 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 21:12:34 ] >>63 なぜPythonだと不安なんだ？ 65 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 21:16:22 ] はっきり言って根幹じゃないほうが好きに弄れて気楽だな 66 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 22:27:20 ] CentOSはRHELクローンなので RHELがPythonのバージョンを変えない限り変わらない んで、そのRHELの実験的な実装の意味合いを持つFedoraでは Python 2.6に移行済みでPython 3.xも同時にインストール可能となっている なんで、RHEL6が登場するまで待てば、自然とPython 2.6になる >>65 RedHat系はyumも含めてPythonがシステムツールに入り込んでるから 確かに、気軽に/usr配下にライブラリとか入れれないよね まぁ、61の言うとおり『入れんな』ってことなんだろうけど 67 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 22:51:22 ] OSの根幹にかかわる部分をperlで書くのは不安だ Rudyじゃなぜダメなんだ 68 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 22:56:01 ] virtualenvがあるから /usr/lib/python2.4 以下にライブラリをインストールなんて 必要ないし、新しいPythonを使いたかったら /usr/local/python2.6 にでも インストールすればいい。 69 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:04:22 ] windows使えば解決 70 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:38:12 ] >16 前スレ 999 だけどリロードしないで激しく時差ぼけレスしちまったぃ まあゆるーく続けますか(matplotlibスレの方がいいかも?)。 numpy,R,matlab等のそれぞれの比較早見表見つけた (使い分ける人向け? っぽいので普通はあまり意味がないかも) mathesaurus.sourceforge.net/ ぐぐって遭遇した1,2年前の話題 Python+Scipy+Matplotlib vs Matlab? news.ycombinator.com/item?id=363096 71 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:38:54 ] 文句あるなら根幹はCで書け 72 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:44:21 ] C は良い言語だよな。メモリ空間の隅々まで自由自在にアクセス出来るし。 73 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:47:10 ] 逆に言うとCPUやレジスタは隠蔽してるので、Cで手に入る自由はメモリだけだな 結局現存するほとんどのOSの機能がCによって提供されてるってのが Cの力だと思っている 74 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 23:56:43 ] もうわけワカメｗ 75 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 00:44:09 ] 73ｗｗｗ 76 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 01:04:47 ] アセンブラが無いと話にならんな 77 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 04:56:14 ] テカテカ 78 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 05:21:04 ] まだやってたのか 79 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 20:26:41 ] 例外処理ってのは、通常の処理手順とは異なる手順で処理するときに使うもんだよ。 引数がintの時も同じように計算して返すのに、なんでわざわざ例外処理でやるんだ。 普通の条件分岐で十分だろ。 80 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:04:47 ] まだやってたのか 81 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:11:20 ] Ruby スレで GUI が無いって騒いでるな 82 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:14:12 ] Python は wxPython の日本語の紹介がけっこうあるからなぁ。 83 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:38:27 ] wxPythonも2~3年くらい前はあまり見なかった wxRubyは当時も今もあまり見ない wxPythonの利用者の方が増えてるってことだよね 84 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:45:19 ] >>79 じゃあ、int('fdasl')と入力したときに、どういう風に返せば満足なの？ 0返すなんて糞仕様は勘弁だからな。 85 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 22:12:26 ] def parseInt(s, default=None): 　　try: 　　　　return int(s) 　　except ValueError: 　　　　return default みたいなのをたぶん前スレで誰かが言ってた いづれにしても、自分で関数作ればよかろう 86 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 22:21:36 ] >>79 「例外は本当に例外的な場合にだけ使う」って、誰が言い出したのか知らないけど、 真っ赤なウソだよ。 例えば、ファイルを開くときに、ファイルが存在しなかったら IOError を出すけど、 開こうとする前に os.path.exists(filename) して存在を確認してもパーミッション等の 条件で開けないかもしれない、HDDがリードエラーを出すかもしれない、 チェックしたときはあったファイルが開こうとしたときに絶妙なタイミングで消えるかも しれない、etc... で、事前チェックしても例外処理は外せない。なら、事前チェックと 例外チェック両方するより例外だけチェックする方が合理的。 特にPythonは、 for i in x: でも中で StopIteration 例外が飛んでるくらい、例外を 気軽に使う言語。 87 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 22:23:46 ] parseInt('0', 0)とか考えるとやっぱいらないかな ってこの話題前にもあったね Pythonのお勉強 Part35 pc12.2ch.net/test/read.cgi/tech/1253535109/395 88 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 22:32:49 ] >>86 エラーは全部例外でいいと思うんだよな 89 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 23:03:32 ] 発生した例外を処理しないと必ず止まるってのは本当にありがたい たまにCで書くとつくづく思う 90 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 00:36:29 ] try: 　raise SyntaxError() except SyntaxError: 　print 'foo' は期待通りに動作するのに、 try: 　@ # <- syntax error except SyntaxError: 　print 'foo' は動作しないんだなぁ。。 文法ミスがあった時点でそれ以降のスクリプトの内容の解釈は不可能だから当然なんだけど、なんか気持ち悪い。 91 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 00:45:51 ] print "hello" @ # <- syntax error これでhelloと表示されないのが気持ち悪いか? 92 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 02:30:59 ] 多重ループを抜けるのに例外を使うのはどう？ 93 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 02:35:50 ] ええでしょう 94 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 09:13:41 ] ええー 95 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 10:28:35 ] >>91 後ろでもそうなるのか。ほう。 syntax errorで動かないことはいいのだが、ユーザがSyntaxErrorをraiseできるのはどういう解釈なんだ？ 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アホだと思う

---

---

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

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