トップページ⇒tech
1001コメント273KB

Pythonのお勉強 Part36

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/01/31(日) 16:50:08
Pythonオフィシャルサイト
http://www.python.org/
日本Pythonユーザ会
http://www.python.jp/Zope/
まとめWiki
http://python.rdy.jp/
関連スレ
http://find.2ch.net/?BBS=ALL&TYPE=TITLE&STR=python
前スレ
http://pc12.2ch.net/test/read.cgi/tech/1253535109/
0153デフォルトの名無しさん2010/02/12(金) 09:56:35
アセンブリでいいじゃん
0154デフォルトの名無しさん2010/02/12(金) 09:56:58
>>152
　:ﾊ_ﾊ:ﾊ_ﾊ:.
:(;ﾟ∀ﾟ)ﾟ∀ﾟ;):　 ｼｨｨｨｨ ──!!
:(´`つ⊂´):..
と_　))(_　つ:
0155デフォルトの名無しさん2010/02/12(金) 10:05:12
ctypes で書いてたら表面だけ python
中身ほとんど C っていうのもありえる
0156デフォルトの名無しさん2010/02/12(金) 10:26:53
>>139
wxは独自のメモリ管理してるから
いちいちDestroy呼ばんとえらいことに

>>155
でもトライアンドエラーが簡単だから
ついpython使っちまう

そーいやPILってCのI/F持ってんだな
本家の解説のソースがImagingObjectをImagingって
書いてあってけっこーはまった
0157デフォルトの名無しさん2010/02/12(金) 11:14:54
C上主義者が湧いてきたな
0158デフォルトの名無しさん2010/02/12(金) 15:05:04
>>156
サンクス

>>139
>wxは独自のメモリ管理してるから
>いちいちDestroy呼ばんとえらいことに

まじか
PyQtに乗り換えるか
0159デフォルトの名無しさん2010/02/13(土) 00:49:02
PyQtといえば、Nokiaだかその関連の研究所だかが、PyQtと互換なライブラリ作ってる。
http://www.pyside.org/

どうやら、PyQt作ってるriverbankに「オプソ版をGPLじゃなくLGPLにしてくれ」と頼み込んだが交渉決裂して、作ることにしたらしい。
将来的にどっちが強くなるんだろ。
0160デフォルトの名無しさん2010/02/13(土) 00:52:09
GUIライブラリのラッパーは単純なんだけどAPI等の数が多すぎて日曜プログラマにはきついね。
0161デフォルトの名無しさん2010/02/13(土) 01:29:54
x API の数が多すぎて

o Framework の数が多すぎて
0162デフォルトの名無しさん2010/02/13(土) 04:03:55
Pythonをコード読むためにざっと文法なぞってて疑問に思ったんだけど、
どうしてswitchやインクリメント演算子が存在しないの？
if-elseが連なってるのは効率がすごく悪そうなんだけど

あと、str.lenじゃなくてlen(str)なのが地味に気になった
0163デフォルトの名無しさん2010/02/13(土) 04:46:00
>>162
気持ちはわかります 漏れの Python 初体験時の感想を書いときますね

●インデント
最初のうち数回は for hogehoge: のあとインデント忘れたりするけれど
慣れるとほとんど気にならないレベル 空気のような存在

●式と文が厳格に分かれている
これは慣れるまで時間掛かった 今でもちょっと面倒と思うケースはある
if (hoge = fuga()) == piyo: とか
if (m = re.compile(r'h(.*)e', re.I).search('hageHOGEfuga')) is not None:
みたいな書き方が出来ないのでもどかしい
(Python 的には「うっかりバグ」を防ぐためなんだと思う)

●switch
if ... elif ... elif ... else ...
も悪くない(っていうかこっちの方が汎用的で C/C++ 的な switch より便利だぜ)
Ruby は case で出来るけどね

●インクリメント演算子
a += 1
で良いと思う(Ruby もそうだし)
*dst++ = *src++;
不満はみたいな書き方が出来ないかなーっていうくらい
それほど不満はない

●str.lenじゃなくてlen(str)
これも慣れるまで何で str.len() がないんじゃーと思ってた w
たぶん Ruby 中毒になっていたんだと思う
split() とか match() とか search() とかでも戸惑うケースがあるね
あとは join() かな
慣れの問題
0164デフォルトの名無しさん2010/02/13(土) 04:47:53
>if-elseが連なってるのは効率がすごく悪そうなんだけど

効率の話だよね
0165デフォルトの名無しさん2010/02/13(土) 07:25:33
>>163
読みながらいろいろと弄くってきた。
現時点ではPythonの方向性というか、ターゲット層がよく分からない。

とりあえず、
if 0 < a < 128 みたいな条件式が通ったんだけど、一種の三項演算子扱いなのか？
手元の資料だとnotは論理否定の役割しかないそうだけど、if a not in b は別なのか？
多次元配列やハッシュの代入に複数行使った場合、どこまでインデントが崩壊していいのか？
あたりが未解決。

最近の主要言語がC#, Rubyなので、lenやjoinは非常にむず痒い。
面白そうな言語ではあるんだけれども、もう一押し何かが欲しいところかな。
いろいろ動作確認したりでまだ初学用の資料すら読み終えてないので、なんとも言えないけどね。

switchがない理由について検索したけど、
「switchに頼るのはOOが理解できていない証拠！」みたいなサイトが一杯出てきてちょっと引いた。
まあ、仮にswitchが導入されていたとしても、インデントの仕方で誰かが文句言いそうだけどｗ
0166デフォルトの名無しさん2010/02/13(土) 07:28:56
>>162
len(obj)
は
obj.__len__()が呼ばれる
0167デフォルトの名無しさん2010/02/13(土) 07:53:13
なんか評論家みたいな上から目線が気にいらないのでつっかかってみます。

なんでそんな細かな言語仕様が気になるの？ 言語が違うんだから他の
言語と記述方法が違うのはあたりまえだと思うんだけど。

switchがあったら便利だというのは同意だけど、インクリメントなんか
スクリプト言語には本来要らないよ。i = i + 1とi++では機械語レベル
ではたしかに命令数が違う。コンパイラにとってはそれ重要だけど、
スクリプト言語にとってそれがなんだというのか。

結局君は書き慣れた記述法じゃないことが不満なんじゃないの？
たとえば「インクリメントが実装されました。Delphi式のinc(i)です」
ってことになったらそれはそれで文句あるんでしょ？ それはインクリ
メントが欲しいんじゃなくて慣れた記述法にしてほしいってだけのことだよ。

言語が違えば記述方法は違う。それは違う言語を学ぶ際に最低限わきまえる
べきことだよ。

それからターゲットはRubyとほぼ一緒だよ。そんなことRuby使ってる
んならわかるでしょ。まつもとさんだって「ああPythonあるからRuby
いらないかもw」とか言ってるしね。

っていうか「もう一押しほしい」って誰に言ってるの？ 君のために誰が
一押ししてくれることを想定しているのか教えてほしい。
0168デフォルトの名無しさん2010/02/13(土) 07:58:18
>>165はGoスレあたりのコピペ改変だろうきっと
0169デフォルトの名無しさん2010/02/13(土) 08:17:13
いいよ、もうみんなS式で書くことにしようぜ。
0170デフォルトの名無しさん2010/02/13(土) 08:23:37
インクリメントはインプレースな演算なのに対して
数値オブジェクトはイミュータブルだからインクリメントは実装できない
という認識は正しい？
0171デフォルトの名無しさん2010/02/13(土) 08:31:31
>>166
なるほど。そういう実装をしているんですね。
さんくすです。

>>167
ちょっと言葉悪かったですね。失礼。

慣れた記述法が欲しいってのは大体正解です。三項演算子とか大好きですし。
これが全然違う文法ならともかく、似通っているのに「微妙に違う」から違和感を覚え、
その違和感による不満を消すために理由や事情があるのなら知りたいと思うんです。

Pythonは確かに支持されている言語なので、支持されるに足る理由があるとは思っているのですが、
どうにもそれが実感できないので、自力にせよ他力にせよ、Pythonの魅力をはっきりさせたいというのが
もう一息っていう吐露ですね。馬鹿にしているようにも読めるレスだったので、その点は謝罪致します。
0172デフォルトの名無しさん2010/02/13(土) 08:57:46
違和感があるのはあんたがまだpythonに慣れてないだけ
switchとかインクリメントとか野暮な事言うのは
無能なRuby厨かC初心者くらいだろ。
0173デフォルトの名無しさん2010/02/13(土) 09:34:32
switchもインクリメントも実質的に必要ないし、分かりにくい部分すらある
len()は.__len__じゃなくて.lenとか.lengthとか.Lengthとか.countとか.itemcountとか嫌でしょ一種のインターフェースです
みたいな話

しかし最近の言語に代入を評価できるのってあるのか？
0174デフォルトの名無しさん2010/02/13(土) 10:35:31
>>171
Pythonが支持されている理由のひとつ

http://pc12.2ch.net/test/read.cgi/tech/1264635554/448-455

こういうことにならない
0175デフォルトの名無しさん2010/02/13(土) 10:56:39
rubyは実装自体も馬鹿なのか
0176デフォルトの名無しさん2010/02/13(土) 11:15:29
>>171
>似通っているのに「微妙に違う」

似てねーよ
それはお前の都合だろ
0177デフォルトの名無しさん2010/02/13(土) 11:16:44
>Pythonは確かに支持されている言語なので、支持されるに足る理由があるとは思っているのですが、どうにもそれが実感できないので

使い込むとわかる

つまり使い込まないとわからない w
0178デフォルトの名無しさん2010/02/13(土) 11:19:56
最初のうちは unicode 絡んでると良くわからなかった
encode() dekode() のネーミング逆じゃね？とか勝手に思ってた
u"ほげ" の内部コード？が必ず UTF-8 で保持されてると思ってた
そんなこんなで exception 出まくりでなんじゃこれ状態だったが
色んな誤解が解消出来た時点でスムーズに書けるようになった
>>165 みたいな初心者には w 敷居は高いかもしれない
0179デフォルトの名無しさん2010/02/13(土) 11:20:57
>>162
●switch文がない
switchで一回インデント、caseで一回インデントで、
二重のインデントになるし、そうなればif〜elifの連鎖より読みにくくなること必至だから。
何度か議論されてきたけどこの二重インデント問題を解決しないことには……
ttp://www.python.org/dev/peps/pep-3103/

●インクリメント
前置と後置で挙動が変わるのを覚えるのが無駄だし、
だいたい、たった一行で代入、評価、破壊的操作の三種類の動作をするわけで、あんまり直感的じゃない。
たしか演算子オーバーロードでもややこしい実装をしないといけないことがあるし、
実用面でもC的なfor文がないからそれほど問題ないし、あったとしてもあんまりメリットはない。

●lenが関数
基本的にPythonは関数がファーストクラスだから、メソッドより関数の方が取り扱いが楽でいいんだよな。
aをリストとしてsorted(a, key=len)ができるんだぜ。
まぁメソッドでもsorted(a,key=type(A).length)でいける訳だからメソッドだからどうというわけでもないが
0180デフォルトの名無しさん2010/02/13(土) 11:28:11
>switchで一回インデント、caseで一回インデントで、二重のインデントになるし
Ruby の case 方式にすれば？
0181デフォルトの名無しさん2010/02/13(土) 11:38:18
他の言語の記法や便利な道具が増える可能性は今後もあるだろう。
昔は += もなかった。sorted もなかった。

tmpKeyList = myDictionary.kyes()
tmpKeyList.sort()
for tmpKey in tmpKeyList:
　・・・

みたいなこといちいち書いてたよ。
0182デフォルトの名無しさん2010/02/13(土) 11:38:42
>>165
＞Pythonの方向性
読みやすく、書きやすい
ライブラリが一通り揃ってるし、
リンクがどうのビルドがどうのとか面倒なことはないし、
素人がプログラムを勉強するのにもおすすめだし、
綺麗なコードが書きたい玄人にもおすすめ

＞0 < a < 128
これは「(0 < a) and (a < 128)」と評価される。
不等号や等号はandでつながれて評価されるんだよ。
だから0 < a < b < c == d < e < 128なんかも
「(0 < a) and (a < b) and (b < c) and (c == d) and (d < e) and (e < 128)」になる。

＞ not in
not inは演算子扱い。

＞もう一押し
関数がファーストクラスだからProcとかデリゲートとかめんどいことしなくても
関数に関数渡して楽しいことができるよ！！
ジェネレータも使えるからリストの処理も簡単だし、
キーワード引数もかなり強力で、
オプションが大量にあってげんなりするGUI関数を操作するのも楽々だし、
OOの世界で有名なデザインパターンのBuilderパターンとかだって
キーワード引数があるだけでかなり存在意義を失う。

＞switchに頼るのはOOが理解できていない証拠！
あれだ、なんでもOOに頼るのはOOを理解できてない証拠なので、
OOを勉強してそういうことを言ってる輩を見下せるようになるといい。

OO的には多態性を勉強するといいかもしれない
0183デフォルトの名無しさん2010/02/13(土) 11:40:53
>>171
三項演算子
「(A)?B:C」は
「B if A else C」でおｋ
0184デフォルトの名無しさん2010/02/13(土) 12:29:11
>>177
なんとなく分かる程度じゃ便利さが見えてこないって感じね。
痒いところに手が届くような感じだとしたら、ちょっと期待したい。

>>178
あー、そこらへんは確かに全然理解できてないかも。

>>179
一応、インクリメントに関しては強く主張する気はないです。三項演算子と一緒でないのが寂しいだけ。
メリットとかじゃなくて気持ちの問題なので、それを押しつける気はないです。

関数に関しては、若干C#,Java,Rubyの影響を受けすぎたかな。
慣れないうちは絶対str.lenとか書きまくっちゃうだろうけれども、違いを意識するように努力してみます。

>>185
玄人向けみたいな先入観が強かったから違和感があったのかな。
等号・不等号は糖衣構文みたいなものだと思っていいのかしら？

申し訳ないけどデリゲートは大好きなんだけどｗ、
他は確かに慣れれば面白そうかもしれない。素敵な情報をありがとう。

switchに関して調べて出てきたページが、なんというか「Pythonの素晴らしさが分からない奴は馬鹿ｗ」みたいなサイトだったんで、
一時的に嫌悪感が高まって、ついついきつめのこと書いてしまった。本当申し訳ない。

>>183
ありがとう。
でも使いたいのは a = b ? c : d みたいな状況だから、素直に分岐した方がいいかもね。
嫌われがちな書き方だけれども、個人的にはすごく好きなんだ。あくまでも可読性に影響のない範囲でだけど。
0185デフォルトの名無しさん2010/02/13(土) 13:21:21
静的型付けの C# なら、 ICollection.Count で統一できるんだよね。
Javaだと配列がインタフェースに従ってないから、 Collection.size() と
配列の .length が統一できてなくてキモイ。

Pythonのようなダックタイピング言語でも、一般的なメソッドを
広い範囲で統一するために、ICollectionみたいなインタフェースが
必要。で、Pythonで一般的なインタフェースは特殊メソッドで実現される。
コンテナ型の場合は、
__len__() で len(x)、 __iter__ で for y in x: や iter(x)、 __contains__ で
y in x と y not in x が使えるようになる。

Rubyはここら辺どうやって統一してるの？みんな一般的なメソッドの名前を
予約語みたいに覚えて間違わないようにしてるの？それだと、予約語と違って
間違えて使ってしまってもエラーにならないから混乱しない？
0186デフォルトの名無しさん2010/02/13(土) 14:06:52
184じゃないけど、Rubyならモジュールをmix-inする
不注意でモジュールから引き継いだメソッドを
オーバーロードしてしまうかもしれないが
それはオブジェクト指向である以上、不可避なのでどうしようもない

Pythonの特殊メソッドでtraitsを表す手法は
クラスの設計者が自覚的に実装することで
意図が明確に反映できる反面、ちょっと面倒なのも事実

そこら辺のRubyとの違いは思想が現れてて面白いね

話がずいぶん戻るけど、Pythonの行継続は
括弧かトリプルクォートで囲まれるか
バックスラッシュで明示的に継続を表すかしかないので
ルール自体ははっきりしているよ
0187デフォルトの名無しさん2010/02/13(土) 14:09:43
>>184
a = c if b else d でおｋ
0188デフォルトの名無しさん2010/02/13(土) 14:21:04
三項演算子一応使えるけど書いてみるとコレジャナイって感じがして2〜3行に書き直す俺ガイル
0189デフォルトの名無しさん2010/02/13(土) 14:45:24
三項演算子入れ子にするとき()使ってる？

a = b ? c ? d : e : f
a = d if c else e if b else f
a = (d if c else e) if b else f

a = b ? c : d ? e : f
a = c if b else e if d else f
a = c if b else (e if d else f)
0190デフォルトの名無しさん2010/02/13(土) 14:49:53
Pythonは他の言語の類似の機能を
初学者にわかりやすいように単純なルールで実装しているので
逆に他の言語をかじった人が使い始めると
戸惑うところがあるのは否めない

スコープに関するクロージャの話とか"".joinとかlen()とか
Python使っている人には「またか・・・」とげんなりしてしまう無限ループ状態

FAQが和訳されれば改善されるのかね？
0191デフォルトの名無しさん2010/02/13(土) 15:04:05
むしろ他の言語をメインに使ってたことがあるからこそ
単純に書けることに感動する奴（俺）もいるっちゃいるんだけどねぇ
0192デフォルトの名無しさん2010/02/13(土) 15:16:15
for の else なんか目から鱗だよなぁ
0193デフォルトの名無しさん2010/02/13(土) 15:16:53
それもあるね
俺はリスト内包表記をPythonで初めて知って
かなり驚いた

それをきっかけにSchemeやHaskellを眺めてみて
世界が広がった気がする

シンプルに書けるって点では、最近はScalaやClojureに注目
0194デフォルトの名無しさん2010/02/13(土) 15:19:19
{ x | x は偶数} みたいなのから来てるんだっけ？
数学に疎いからHaskell本読むまで気づかなかった
0195デフォルトの名無しさん2010/02/13(土) 15:24:02
Erlang も忘れてやらないでください
0196デフォルトの名無しさん2010/02/13(土) 15:25:39
そうそう
集合の中の要素の条件付けそのまま

中高生が初めて触るプログラム言語として
数学との違和感のなさから、実はHaskellは向いているのではないか
・・・と妄想してしまうw

プログラミングHaskellの訳者の人も、そんなこと書いてたし
0197デフォルトの名無しさん2010/02/13(土) 15:36:23
自分用に三項演算関数でも書けばいいじゃない
0198デフォルトの名無しさん2010/02/13(土) 15:39:41
>>186
Pythonでもmix-inを使って、一部の特殊メソッドを用意するだけで
それ以外を自動で用意する事はできるよ。
昔はUserListとかUserDict, 今なら collectionsモジュール内のABC。

だからPythonとRubyの違いは
1. 特別な関数に特別な名前を付けるか、普通のメソッド名を使うか
2. 他のメソッド名と被らない演算子や関数を使うか、普通のメソッド名を使うか
だよね。
Pythonの方が明示的だけど、Pythonの方が面倒と言うことはない。
0199デフォルトの名無しさん2010/02/13(土) 15:53:12
ウソついた。UserDictやUserListはmix-inじゃないや。
collectionsモジュールが便利なのは本当。
0200デフォルトの名無しさん2010/02/13(土) 16:03:45
なんだびっくりしたｗ
0201デフォルトの名無しさん2010/02/13(土) 16:06:46
>>192
for-elseはたまにしか使わないけど、凄く便利だよね。
try-elseもそうなんだろうけど、使ったこと無い。
0202デフォルトの名無しさん2010/02/13(土) 16:23:36
for-elseってtry-finallyみたいなもの？
0203デフォルトの名無しさん2010/02/13(土) 16:26:02
ちょい違う。
else節に行くのは最後までbreakしなかったとき
0204デフォルトの名無しさん2010/02/13(土) 19:50:01
>>184
a=cond?expr1:expr2;のような使い方でもpython風三項演算子使っちゃうばかりか、
逆に違和感がないと思う俺はpython病気かなぁ？

val = a if a>0 else 0 だと、通常処理を書いてから困ったチャンの処理を書くって流れが例外処理みたいでいい。
max = a if a>b else bだとそういった感じはないけど、英文みたいな感じはしなくもないし、まぁいいかなぁ、と。

けど、ネストは勘弁してほしい。
max = (a if a>c else c) if a>b else (b if b>c else c)
とか、ややこしすぎる。
max = a>b ? (a>c ? a : c) : (b>c ? b : c)
の方がずっと読みやすい。
0205デフォルトの名無しさん2010/02/13(土) 19:58:09
>>202
flg=0
for x in リストとか:
　if ほげほげ:
　　
02062052010/02/13(土) 20:01:29
>>202
ごめ、途中で書いちゃった

flg=false
for x in リストとか:
　if ほげほげ:
　　flg=true
　　break
if not flg:
　むにゃむにゃ

を

for x in リストとか:
　if ほげほげ:
　　break
else:
　むにゃむにゃ

で済ませられる。

例えば、全部試してみたけどダメだったよー、みたいな処理いれる。
0207デフォルトの名無しさん2010/02/13(土) 20:10:47
便利な書き方だけど、直観的な文法ではないなぁ＞for-else
0208デフォルトの名無しさん2010/02/13(土) 20:11:08
簡単な素数計算

for i in range(100):
    for j in range(2,i):
        if i % j == 0:
            break
    else:
        print i
0209デフォルトの名無しさん2010/02/13(土) 20:14:30
>>186
括弧が明示されている限りはインデントを気にしなくていい、と解釈していいのかな？
インデントにちょっとびびりすぎてたかもしれない。さんくす。

>>187
動いた！ありがとう！
三項演算子は消えゆく運命かと思って黄昏れてたので、ちょっと本気で嬉しかった。

>>190
FAQだったのか……すみません。
正直「Pythonは若干ハイレベル」という思い込みと「インデントさえできれば大丈夫」という偏見があったので、
実際に触れてみて、想像と現実とのギャップに戸惑った部分が多いと思う。勝手な思い込みで文句たれて本当申し訳ない。
正直ここでいろいろ言ってもらって、だいぶギャップが埋められたみたいでありがたく思ってる。

>>192
あれは素直に驚きました。
0210デフォルトの名無しさん2010/02/13(土) 20:26:24
Pythonって、他の言語のいいところを参考にしながらもそれをそのまま取り込まず、
常識にとらわれずに、一番合理的な方法を考えるからな。
0211デフォルトの名無しさん2010/02/13(土) 20:30:44
それは無い
0212デフォルトの名無しさん2010/02/13(土) 20:37:15
>>208だと0と1が入るので一行目はfor i in range(2,100):だな
0213デフォルトの名無しさん2010/02/13(土) 20:37:22
つい__dict__をいじっちまう
0214デフォルトの名無しさん2010/02/13(土) 20:50:27
>>209
210みたいなコメントを見ると引く気持ちもわかるが
Pythonの実装は、基本、実用性重視だし
単なる実装の都合上の制限だってある

とりあえず本家サイトのFAQを見るといいよ
http://www.python.org/doc/faq/

General Programming FAQ と Programming FAQ の
目次を眺めると『みんな同じ疑問を持つんだな』と癒されるはず

>>198-199
おぉ、collectionsってdefaultdictだけだと思ってた
この抽象基底クラスのテンプレートはいいね！！
俺のメイン環境は2.5なので使えないけど・・・

便利なものはどんどん真似しあって欲しいね
0215デフォルトの名無しさん2010/02/13(土) 21:57:59
>>207
直感的だよ

そうじゃないと思うのは今まで for - else の無い言語で頭が毒されて来たからだよ
0216デフォルトの名無しさん2010/02/13(土) 22:07:42
>>215
英語的には直感的じゃないような気がする。作者もネイティブじゃないが
0217デフォルトの名無しさん2010/02/13(土) 22:27:49
値がを返す構文は基本的に後置修飾だから
一貫性はあるんだけどね
0218デフォルトの名無しさん2010/02/13(土) 22:31:02
>>215
直感的にはbreakしたときに実行される気がする。
何時だったか同じ話題が出たときはそんな意見が多かった印象
0219デフォルトの名無しさん2010/02/13(土) 23:15:00
>>218
一時期日本語ドキュメントもbreakしたときに実行されるって書いてあったw
それはさておき、実際問題としてbreakしなかったときに実行する方が需要あるし、
「最後まで止まらなかった場合に実行する」という意味で try-else と整合性あるし、
やっぱり else は今の仕様が合理的だと思うよ。
0220デフォルトの名無しさん2010/02/13(土) 23:21:37
というかbreakしたときに実行ってあんまり意味ないよねｗ
breakが1箇所ならその直前に書いとけばいい話だし、複数箇所でbreakすることも少ないし。
0221デフォルトの名無しさん2010/02/14(日) 02:25:56
>>218
もしその意味なら finaly かな
else だったら誤解は無いと思う
0222デフォルトの名無しさん2010/02/14(日) 08:25:44
>>221
finaly なら break してもしなくても return しなくても実行される気がする。
0223デフォルトの名無しさん2010/02/14(日) 11:50:41
いろいろと細かい資料とか読んで>>210の言ってることにちょっと納得。
個人的には、クラスの定義方法を見て、今までの細かいとことか結構どうでもよくなった。
これは……慣れるのに相当時間かかりそうな気がする。
他のOO言語から入った人は、特に違和感とかなかった？ 自分毒されすぎかな？
0224デフォルトの名無しさん2010/02/14(日) 12:00:45
>>223
むしろ、違いを見つけてはなぜそうなっているのかを知るたびに
「なるほど！」の連続で楽しかった。
0225デフォルトの名無しさん2010/02/14(日) 16:19:59
>>222
try:
　print 'a'
　raise 'b'
　print 'c'
except:
　print 'd'
else:
　print 'e'
finally:
　print 'f'


for 中で break することを raise したことに置き換えるなら (>>218 の言う直観ってそういう意味に取れたから)
except と finally へ行ってくれれば良い訳で
else はあくまで最後まで except へ行かずに済んだ場合の処理ということで直観に従ってると感じる
0226デフォルトの名無しさん2010/02/14(日) 16:43:13
>>223
元々はアセンブラとか C をやってたけど
( FILE* みたいな構造体をクラス/インスタンス的に使う設計や実装も当時やってた )
C++ やり始めるときに先輩から薦められて「Eiffel オブジェクト指向入門」を読んで
Eiffel を通してオブジェクト指向の基本的な考え方をメイヤーさんから習った
(これはかなり良い経験だったと今でも思っています)

その後 C++ を使ってるうちに何かが変だと感じつつ
(その頃は C++ が糞だと断定出来る自信がなかった)
Objective-C (Mac じゃなくて StepStone の方) をやって本当の快適さを覚え
その流れで Smalltalk に手を出したものの環境依存が大き過ぎて
出家信者になるのが怖くてどっぷり漬かれずにいたところ
当時流行り出した Perl (のオブジェクト指向部分の実装) は糞だと思って無視
PHP (のオブジェクト指向部分) はマシかなと感じたが若干テストしただけで手を出さず
Zope-Python の存在を知ったが何それ美味しいの？ Zope に環境依存するなんてやだ
と食わず嫌いで Python から遠ざかりつつ勢いで Ruby 教に入信してしまい
Ruby を有難く使っていた数年後に 2ch で Python 厨と Ruby 厨の論戦を目にして
バランスの良い Python に辿り着いたときには Ruby 要らなくなってた
0227デフォルトの名無しさん2010/02/14(日) 18:03:47
三行で要約↓
0228デフォルトの名無しさん2010/02/14(日) 18:15:42
ワナビーがルビ厨になってPython信者に宗旨替えした
0229デフォルトの名無しさん2010/02/14(日) 23:26:21
>>228
それ一行
0230デフォルトの名無しさん2010/02/14(日) 23:32:59
>>229
それ四文字
0231デフォルトの名無しさん2010/02/14(日) 23:49:13
list.sort(reverse=True)
これと

list.sort()
list.reverse()

って実際の動作ではやっぱ前者の方が軽い？
0232デフォルトの名無しさん2010/02/14(日) 23:52:15
試してみればいいじゃな
0233デフォルトの名無しさん2010/02/14(日) 23:53:01
い
0234デフォルトの名無しさん2010/02/15(月) 00:09:40
timeit
0235デフォルトの名無しさん2010/02/15(月) 01:05:55
いっしょだった
0236デフォルトの名無しさん2010/02/15(月) 02:12:48
比較関数でリバースさせるようにしたらどうなるかな
0237デフォルトの名無しさん2010/02/15(月) 02:29:26
>>236
2.5倍くらいかかった

次の案↓
0238デフォルトの名無しさん2010/02/15(月) 02:32:01
[::-1]
0239デフォルトの名無しさん2010/02/15(月) 02:33:21
>>238
はやすぎわらた
0240デフォルトの名無しさん2010/02/15(月) 02:55:06
いっしょってことは、内部的にはreverseの値によってCでの比較関数を変えてるんじゃなく、正順にソートして逆転してるってこと？
リストである必要がないなら、reversed(list.sort())でイテレータにするのもアリかなぁ。
0241デフォルトの名無しさん2010/02/15(月) 07:11:27
list.sort()
list.reverse()
これだと実際に取り出すまで reverse 始まらないのかもね
0242デフォルトの名無しさん2010/02/15(月) 09:27:08
ソースを流し読みした感じだと
list.sort(reverse=True)とlist.reverse()は内部的に同じCの関数を呼び出してる
Python使いが意識するべき速度差じゃないな
0243デフォルトの名無しさん2010/02/15(月) 20:10:50
つまり入り口が違うだけか
0244デフォルトの名無しさん2010/02/15(月) 20:24:52
質問書いた者だけどありがとう
バイトコンパイルされたファイルはreverse()の方が小さかったから何が違うのかと思ったけど同じなのね
0245デフォルトの名無しさん2010/02/15(月) 22:18:46
そりゃまあ引数付きのメソッド呼び出しより、引数なしのメソッド呼び出しの方がバイトコードは小さくなるわなぁ。
0246デフォルトの名無しさん2010/02/16(火) 03:34:52
>>242
それでも list.sort() と list.reverse() 二回呼んでるのは無駄だよね
律速されてるのは C の関数の方だからたまたま影響出ないだけで
0247デフォルトの名無しさん2010/02/16(火) 08:39:02
どういうアルゴリズムでなのかはよく追ってないが
list.sortでreverse=Trueを渡してやると反転処理は2回行われている
インタプリタがもう1行余分に処理するのに必要な計算量は知らないけど
それらのバランスも含めてPython使いが気にするような速度差ではないと言った
0248デフォルトの名無しさん2010/02/16(火) 08:43:57
.sortのreverseフラグはソートメソッドで２行使わないためだろ
ソースでもreverse=Trueって書いてあった方がわかりやすい。
0249デフォルトの名無しさん2010/02/16(火) 08:53:02
木を見て森を見ず
0250デフォルトの名無しさん2010/02/16(火) 09:20:57
乳を見て顔を見ず
0251デフォルトの名無しさん2010/02/16(火) 09:24:13
あなる舐めてかなる舐めず
0252デフォルトの名無しさん2010/02/16(火) 20:51:34
sorted とか reversed とかだと違うんだろうか
■ このスレッドは過去ログ倉庫に格納されています