07/11/18 16:04:53
コロン無いと一行に書けないじゃん
if pred: body
みたいにさ
113:デフォルトの名無しさん
07/11/18 16:25:05
誰が書いても同じ書き方になるのが売りのひとつじゃなかったの?
114:デフォルトの名無しさん
07/11/18 17:03:56
>>113
んなもん、本当に同じになるわけねーじゃんよ
115:デフォルトの名無しさん
07/11/18 17:29:58
>>112
行末の「;」が省略可能なんだから
同様に1行に書く時だけ「:」つけるんで
いいんでないか?
116:デフォルトの名無しさん
07/11/18 17:31:18
self じゃなくて s で済ませば3文字減るな
117:デフォルトの名無しさん
07/11/18 17:40:57
ifとかforやめて全部 ? にすればすごく減るよね。違いは文脈で判断。
118:デフォルトの名無しさん
07/11/18 18:03:47
一番重要なのは可読性であって、打鍵数を減らすことじゃないと思うんだが、と言ってみるテスト。
119:デフォルトの名無しさん
07/11/18 18:23:18
キーワードの短さだけを考えるんじゃねえよ。
可読性もいっしょに考えるんだ。
120:デフォルトの名無しさん
07/11/18 18:28:15
self、selfってうるさいのも可読性を落とすよ
121:デフォルトの名無しさん
07/11/18 18:29:09
>>114
だからってわざわざ複数の書き方を許すような文法にしなくてもいいじゃん
122:デフォルトの名無しさん
07/11/18 18:40:08
self、self ってあって下がるのは読み手のモチベーション。可読性の低下に関しては間接的な影響しか与えないんじゃないかな?
123:デフォルトの名無しさん
07/11/18 18:44:58
わざわざself省略とかなんでそんな無駄なことしなきゃいけないんだ
124:デフォルトの名無しさん
07/11/18 18:57:28
まあぶっちゃけselfには利点の方が多いのだが。
selfをいやがる奴に限って「めんどい」とかそういう低レベルなことしか言わないな。
そういうアホはPythonを使わなくて結構。
125:デフォルトの名無しさん
07/11/18 19:04:50
>>124
禿同。そういうヤツらって実は Python どころか、きちんと機能するコードを書けるかすら疑問。
126:デフォルトの名無しさん
07/11/18 19:18:53
ぶっちゃけとかいうくせに全然ぶっちゃけた話ししてないじゃん。
さっさと利点の方が多いというところをぶっちゃけてみろよ。
単に論破されるのが怖くて隠し玉をださないくせに、出せば勝てる
という根拠の無い自信ででかい態度を取ってるだけに見えるぞ。
127:デフォルトの名無しさん
07/11/18 19:33:41
>>124
むしろselfがキーワードでないのは半端に思えるんだが。
呼び出すときには
obj.method(arg)
と書けるのに
定義では
def method(self, arg):
と書かなければならないのも、汚い。selfがキーワードでないために
こう書かなければならないのだとしたら、それこそバカげている。
メンバアクセスを self.member のように書かせること自体は、
可読性のために良いと思えるんだが。
128:デフォルトの名無しさん
07/11/18 19:44:45
>>127
class.method(obj,arg)
129:デフォルトの名無しさん
07/11/18 19:49:32
>>128
常にそう書かせるのであれば一貫性はある。だが、実際にはそうではない、でしょ。
限定的に
obj.method(arg) にだけ第一引数省略の特権を与える合理的な理由があるとは
思えない。
130:デフォルトの名無しさん
07/11/18 19:52:57
関数がファーストクラスオブジェクトでない言語しか
知らないゆとりカワイソス
131:デフォルトの名無しさん
07/11/18 19:56:34
>>130
それ、全然関係ないだろ
OCamlでクラスのメソッドを定義する時に、いちいち第一引数の
selfなんて書かせないぞ
Pythonがそうであるのは単に実装都合であり、要は手抜きだ
132:デフォルトの名無しさん
07/11/18 20:08:48
第一引数のself書かせないと。それは不便だな。
133:デフォルトの名無しさん
07/11/18 20:12:38
君らの脳内の解釈より、他人が見た時の可読性が重要なんだよ。
134:デフォルトの名無しさん
07/11/18 20:12:52
それがインスタンスメソッドなら第一引数がレシーバであるのは自明で、
定義に明示的にselfを書かせないとしても、レシーバを第一引数にして
クラスメソッドとして呼び出せるようにすることも出来る。
インスタンスメソッドにわざわざ常にselfを明示的に書かせるPythonは
センスが無い。
135:デフォルトの名無しさん
07/11/18 20:13:47
>>133
レシーバのselfをわざわざ書かせることも、それが実はキーワードでも
何でもなくて、sと書いてもいいことも、可読性の向上に何ら貢献しないのだが。
136:デフォルトの名無しさん
07/11/18 20:18:47
>>135
それは、あなたが賢いからなのでしょうね。私には少なくとも可読性の向上に貢献しています。
137:デフォルトの名無しさん
07/11/18 20:18:59
1) メソッドには第一引数が必要という割り切った仕様。欠点より利点が多いことは,ゆとりプログラマ以外には説明不要なほど自明なこと。
2) 暗黙に第一引数の名前が決まっていた方がみんな便利。
3) だからselfと書く。
これが分からない奴は他の言語使えばいいと思うよ。
ぶっちゃけクラスメソッドの場合の第一引数はclsだぜ。
文盲でない奴はPEP8を読もうな。日本語訳もあることだし。
138:デフォルトの名無しさん
07/11/18 20:22:52
>>137
「欠点より利点が多い」理由を説明してくれ。
obj.memfunc()
だけを省略可能にする合理的理由についてもな。
決まっていたほうが便利というのなら、それこそコンベンションでなく
キーワードにしろ、と。
あんたはPythonが現にそうである、という説明をしているだけだ。
それが良いものであるかどうかという説明にはなっていないぞ。
139:デフォルトの名無しさん
07/11/18 20:27:39
140:デフォルトの名無しさん
07/11/18 20:30:15
929 名前: デフォルトの名無しさん [sage] 投稿日: 2006/10/18(水) 23:39:44
(´-ω-`)
Guidoは疲れ切っていた
煩雑な構文、人によって違うスタイル、そして見えない変数に。
(´-ω-`)Zzz
そして眠ってしまった。しかし……
ヒラメキ━━(゚∀゚)━━!!
単純な構文!スタイル強制!変数はすべて明示!!
俺言語デキタY⌒Y⌒Y⌒Y⌒Y⌒Y⌒(。A。)!!!
switch...case欲しいだと? (゚Д゚ )ヤダ!!
インデント構文がSM? (*´д`*)ハァハァ
クラスの記述が面倒? ( ´_ゝ`)フーン Javaでもやれよ
変数を暗示で使えるようにだと? (^A^)っPerl
俺言語ヽ(´ー`)ノバンザーイ
141:デフォルトの名無しさん
07/11/18 20:30:49
obj.memfunc() が本当に省略なのかについて
142:デフォルトの名無しさん
07/11/18 20:32:38
欠点:
ゆとりが理解不可能なこと。
利点:
それ以外全部(wwww
>obj.memfunc()
>だけを省略可能にする合理的理由についてもな。
意味不明。ゆとりなりに頭を使って,丁寧に説明してくれよ。
それが礼儀ってものだろ(wwwwww
>決まっていたほうが便利というのなら、それこそコンベンションでなく
>キーワードにしろ、と。
嫌だね。たまにはselfというローカル変数を作りたくなることもあるし(www
>あんたはPythonが現にそうである、という説明をしているだけだ。
そして,お前はまずPythonの現状をよく調べろ。
作者タソがみずからselfの存在意義について言及している文章がたくさん見つかるよ。
あ,ごめん,日本語もできないゆとりが英語なんて読めるわけないよな(wwwwwwwwwww
143:デフォルトの名無しさん
07/11/18 20:34:30
>>138
>決まっていたほうが便利というのなら、それこそコンベンションでなく
>キーワードにしろ、と。
キーワードは主にパーサーのためにあるのであって,ゆとり脳のためにあるのではないのだが。
144:デフォルトの名無しさん
07/11/18 20:34:47
説明できない人は要りません
145:デフォルトの名無しさん
07/11/18 20:37:01
Python信者発狂。
インスタンスメソッドのレシーバにselfだのthisだの書かせない
大半のオブジェクト指向言語よりPythonの方法のほうが「いいものだ」
と無根拠に主張して、その理由は説明できんらしいな。
146:デフォルトの名無しさん
07/11/18 20:38:08
>>142
あまりイジめちゃ可哀想だよ。この議論、ゴールドセイントにスティールセイントが戦いを挑むようなモンなんだから。
147:デフォルトの名無しさん
07/11/18 20:38:38
>>145
いやいや信者かどうかは微妙だぞ。
ここぞとばかりに荒そうとしているのかもしらん。
かなり頭悪そうだからなあw
148:デフォルトの名無しさん
07/11/18 20:38:42
> 嫌だね。たまにはselfというローカル変数を作りたくなることもあるし(www
Python信者は自分の都合に応じて「可読性」と言い、
時にはselfというローカル変数を作ってコードの読者を罠にはめるわけか。
で、classだのwhileだのforだのinだのというローカル変数を作りたくなることは
ないのかい?
149:デフォルトの名無しさん
07/11/18 20:41:38
他の予約語がもっと多い言語を使っているヤツがゴチャゴチャ言うな。
150:デフォルトの名無しさん
07/11/18 20:43:32
何だその煽りにもなってない煽り。
151:デフォルトの名無しさん
07/11/18 20:44:31
>>145
逆に大半のオブジェクト指向言語の方法のほうが「いいものだ」という、あなたの根拠を聞きたいものだね。
152:デフォルトの名無しさん
07/11/18 20:44:48
喧嘩すんなよ。というか、self云々はスレ違いだろ。
selfはウゼーってことで終了しようよ。
153:デフォルトの名無しさん
07/11/18 20:46:08
>>148
>で、classだのwhileだのforだのinだのというローカル変数を作りたくなることは
>ないのかい?
ぶっちゃけないよ(wwwwwwwwwwwwwwwwwwwwwwwwwww
154:デフォルトの名無しさん
07/11/18 20:46:41
>>153
selfはあるのに?
論理破綻はなはだしい。
155:デフォルトの名無しさん
07/11/18 20:47:33
>>148
高々20数個の予約語も覚えられず,予約語と同名の変数を作りたくなることがあるとは!!!
ゆとり脳恐るべし!!!!!!!
156:デフォルトの名無しさん
07/11/18 20:48:06
>>151
インスタンスメソッドの第一引数は自明なのだから、その定義において
毎回それを書かせるのは、obj.mem(obj)が冗長であるのと同じ理由で
冗長であり、可読性にも貢献しない。それで十分では?
157:デフォルトの名無しさん
07/11/18 20:48:09
>>155
お前は文盲か。
158:デフォルトの名無しさん
07/11/18 20:49:10
>>154
155が言っているとおり,予約語と分かっているキーワードを変数名として使いたくなることなんてねえよ(wwwwwwwwwwwwwwwwwwwww
159:デフォルトの名無しさん
07/11/18 20:49:44
>>152
全てのselfがウザいと言っているのではない。
インスタンスメソッド定義にわざわざ「常に」selfと書かせるのが
ウザいと言っている。
「常に」書くってどういう意味かわかるか?
場合わけがそもそも存在しないんだから、それは自明なんだ、自動化できるんだ。
それをわざわざ人手でやらせてるんだ。
馬鹿馬鹿しいことこの上ない。
160:デフォルトの名無しさん
07/11/18 20:50:10
>>158
文盲がお前とアイツと二人いるってことか
161:デフォルトの名無しさん
07/11/18 20:51:21
>>158
つまりselfがもともとキーワードとして設計されていれば、文句を
言わないわけだ。
自分のバカさ加減、論理矛盾に全く気づいていないようだねえ。
162:デフォルトの名無しさん
07/11/18 20:52:21
>>159
>インスタンスメソッド定義にわざわざ「常に」selfと書かせるのが
>ウザいと言っている。
self書かない方が逆にまぎらわしくね?(wwwww
163:デフォルトの名無しさん
07/11/18 20:54:11
>>162
メソッドのプリフィックスにm_つければおk
164:デフォルトの名無しさん
07/11/18 20:56:11
(w
で抽出すると、バカが浮き彫りになりますな。
165:デフォルトの名無しさん
07/11/18 20:57:29
>>164
164が抽出されました(wwwwwwwwwwwwwwwwwwwwwww
166:デフォルトの名無しさん
07/11/18 20:58:04
で、別にselfはもういいでしょ。
見る人によって利点でもあり欠点でもあるってことで。
すれ違いのことで喧嘩するとか、まともな大人とは思えませんよ。
167:デフォルトの名無しさん
07/11/18 20:58:57
>>165
小学生ですかあなたは。
168:デフォルトの名無しさん
07/11/18 20:59:14
だいたいさあ、Python全肯定しちゃう人ってなんなの?Pythonと自我が融合してんの?
169:デフォルトの名無しさん
07/11/18 21:00:17
しかしキーワード増やせなんてプログラマの発言とは思えんな
170:デフォルトの名無しさん
07/11/18 21:01:18
ようするにですね、僕がselfを持ち出したのは、>>166の結論を
selfに対してではなく、ブレースvsインデントの議論に対して
導ければと思ってなのです。ですからスレ違いではありません。
171:デフォルトの名無しさん
07/11/18 21:01:38
selfに欠点があるのは認めるよ。
そして星の数ほどの人間が、selfをなくす提案をしてきたんだ。
でもそのたびに、self不要論者は論破されて負け続けてきた。
そして誰も、selfなくせと言わなくなりましたとさ。
172:デフォルトの名無しさん
07/11/18 21:02:05
別にselfをキーワードにしなくても、省略可能にすることは可能だろうけどね。
173:デフォルトの名無しさん
07/11/18 21:06:35
もう俺言語を作るしかない。基本は型無しのC#。これ。
174:デフォルトの名無しさん
07/11/18 21:08:55
>>171 からすると、
ここでselfについて議論しているヤツらはソースが英語だからと言ってチェックを怠ったヤツらの集まりということで終了。
175:デフォルトの名無しさん
07/11/18 21:17:14
残念。2chはその英語のソースをチェックしない人たちの集まりなのです。
176:デフォルトの名無しさん
07/11/18 21:18:24
まあFAQなんだけどな。
URLリンク(www.python.org)
ゆとり脳のためにFAQを翻訳してやるけど,「よくある質問」ってやつだよ。
英語を勉強して5年後くらいに読んでみれば?(wwwwwwwwwwwwwwwwwww
177:デフォルトの名無しさん
07/11/18 21:21:42
虎の威を借る狐だな
178:デフォルトの名無しさん
07/11/18 21:25:14
頭のないゆとりよりはマシだろう
179:デフォルトの名無しさん
07/11/18 21:25:27
>>176
理由の1および3は、メソッド定義の第一引数のselfが好ましい理由の説明に
なってないな。
常にself.memberと書かせたほうがいい理由にしかなっていない。そしてそれは
別に否定はしない。
理由の2については、clazz.mem(obj, arg)と書けていいよ、と言っているわけだが、
別にメソッド定義でわざわざselfを手で書かせなくとも、そう呼び出せるように
設計することは可能なわけで、理由としては非常に弱いと言わざるを得ない。
180:デフォルトの名無しさん
07/11/18 21:30:41
ところで159は自分が場合分けしてる事に気づいてない模様
181:デフォルトの名無しさん
07/11/18 21:31:43
バカがひとりいると、バカを納得させるために細かいルールを作る必要がある。
バカは大抵暇だから、バカほど声が大きい。バカには仕事をさせない方が組織の能率が上がるから。
それがウザイので、他の言語に行ってくれていいよ。
182:デフォルトの名無しさん
07/11/18 21:34:53
>>176
次からは、生半可な自分の知識で煽って壮絶に敗北する前に、そのURLを提示するんだ。
今回の経験を生かせば、お前もようやくゆとり脱出の足がかりが出来たことになるよ。
183:デフォルトの名無しさん
07/11/18 21:36:31
>>180
Pythonは第一引数のselfのありなしでインスタンスメソッドかどうかを
判別しているのではない、でしょ。
つまりselfは冗長で余計。
selfをsとか書けたからといって、Python信者が好きな可読性とやらが損なわれるだけ。
184:デフォルトの名無しさん
07/11/18 21:37:25
>>182
問題提起する前にFAQを先に読んどけよ(wwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwww
185:デフォルトの名無しさん
07/11/18 21:38:16
草はやし過ぎ
>>179に自分で回答できるぐらいの頭はないのか
無いんだろうな
186:デフォルトの名無しさん
07/11/18 21:38:46
>>181
今ここに実例がいますしね(あなたのことではありません。念のため)
187:デフォルトの名無しさん
07/11/18 21:40:47
あえて言おう、ググレカス、と(wwwwwwwwwwww
188:デフォルトの名無しさん
07/11/18 21:41:10
>>184
知ってる?
2chで煽りに使われるwの数は、自身の悔しさ度が反映されるんだよ?
実際どんどん多くなってるでしょ?イライラしすぎでみてらんない。
189:デフォルトの名無しさん
07/11/18 21:42:09
>>186
そう、あなたのことです。(念のため)
190:デフォルトの名無しさん
07/11/18 21:45:44
自分のことを言われていると思ったのか…
191:デフォルトの名無しさん
07/11/18 21:47:19
こういう時のために2ch先人たちは「オマエモナー」という予約語を用意してくれているようですね。
192:デフォルトの名無しさん
07/11/18 21:48:14
>>190
Pythonのルールに従えないバカに言われたくないだけ
193:デフォルトの名無しさん
07/11/18 21:49:31
Pythonを使う際にルールに従うのは当たり前ってか、そうじゃなきゃ使えない
言語設計に疑問を持つのは別の次元の話
Python信者は頭が良すぎて感心するわ
194:デフォルトの名無しさん
07/11/18 21:51:36
じゃあ、宴も酣ですし、そろそろ>>170に、ここらインデントの議論に導いてもらいましょうか。
195:デフォルトの名無しさん
07/11/18 22:14:00
170は逃げたようです
196:デフォルトの名無しさん
07/11/18 22:34:23
逃げたんじゃないよ、
FAQを読んでるんだよ(wwwwwwwwwwwww
197:デフォルトの名無しさん
07/11/18 22:37:32
(w クンは黙っててください。息が草臭いです。
198:デフォルトの名無しさん
07/11/18 22:38:32
(wも予約語にすればいいんじゃね?ww
199:デフォルトの名無しさん
07/11/18 22:41:32
_, ._
( ・ω・) んも~
○={=}〇,
|:::::::::\, ', ´
、、、、し 、、、(((.@)wvwwWWwvwwWwwvwwwwWWWwwWw
200:デフォルトの名無しさん
07/11/18 23:40:38
草刈りなんてしてないでインデントの議論に導いてくれよ>170
201:デフォルトの名無しさん
07/11/18 23:48:24
私は170ではありませんまので、その問いは意味が不明です。
202:デフォルトの名無しさん
07/11/19 00:42:35
個人的にself以外の文字列をselfに使ってる人居ませんか?
203:デフォルトの名無しさん
07/11/19 00:48:31
myがいいね。my希望
204:デフォルトの名無しさん
07/11/19 02:52:07
まず、Pythonにあるのは関数で、メソッドではない。
obj.method という式は、 class.method の第一引数に obj をbindしている。
なので、
m = obj.method
m()
とするだけで delegate になる。
205:デフォルトの名無しさん
07/11/19 03:01:04
次に、selfを省略できないワケ。
動的言語は、オブジェクトのメンバがコンパイル時に決まらない。
変数の参照で、その変数がローカル変数なのかメンバ変数なのかが
関数の定義を見るだけで区別できないのは非常に危険なので、メンバ
変数への参照はローカル変数への参照から区別しなければならない。
Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
それはあまりPythonicでは無いだろう。
206:デフォルトの名無しさん
07/11/19 10:43:59
>>204
@classmethodとか書かせるし、チュートリアル等のドキュメントで
しっかり「メソッド」と書いてあるのに、
>Pythonにあるのは関数で、メソッドではない。
というのはどういう意味で言ってるんだ?
207:デフォルトの名無しさん
07/11/19 11:53:41
↓こういう風に書けるってことだと思うが、
本当のところは本人に聞いてけろ。
class ClassA:
def __init__(self):
self.x = "hello"
def methodB(self):
print "B:", self.x
def funcC(self):
print "C:", self.x
ClassA.methodC = funcC
funcB = ClassA.methodB
a = ClassA()
a.methodB()
funcB(a)
funcC(a)
a.methodC()
208:デフォルトの名無しさん
07/11/19 12:18:17
なるほど、意図は理解した。
JavaScriptでもそのように書けるが、JavaScriptでは引数のthisは書かなくていいな。
209:デフォルトの名無しさん
07/11/19 15:16:26
>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。
オレはこれが嫌いでRubyやる気無くした(ww。
関数っつーか,厳密に言うと「呼び出し可能オブジェクト(callable object)」だと思う。
ゆとり脳に理解不能な話題はやめてさ,そろそろインデントの議論に戻らないか?
210:デフォルトの名無しさん
07/11/19 19:34:17
>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。
privateなメンバはアンダーバーを二つつける、という、割とよく似た性質のルールがPythonにもありますけど。
Pythonicでは無いから、とか意味不明な理由を持ち出すのは止めといたほうが。
211:デフォルトの名無しさん
07/11/19 19:36:35
>>202
Python3.0になったら「俺」にする予定
212:デフォルトの名無しさん
07/11/19 23:18:06
>>210
そのルール知らなくても、private使わないでプログラム書くのは簡単。
そのルール知らなくても、他の言語のプログラミング経験があれば
そのルールを使ったプログラムを読むことが可能。
それがRubyやPerlの「知らなきゃ読めない」ルールとの差。
Python方式でもRuby方式でも実現できることを、Python方式で
実現しているということに、「Pythonicだから」という以上の理由が
何故必要?
213:デフォルトの名無しさん
07/11/21 00:26:15
>>212
あのさぁ、その「知らなきゃ読めない」とかも意味不明だってことに気づいてないでしょ。
例えば、"リストの内包表記"を知らなくて読むことが書くことが出来るか?
出来ないんだよ。
もし「それぐらい推測出来る」とかバカ言うなら、Rubyの@つけるルールだって推測できるだろ。
>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。
第一、210のレスは↑に対するレスだって理解できてる?
Rubyのようにメンバ変数を区別するのに専用の記号とルールを用意するりはPythonicじゃないとかアホ言ってる奴に
Pythonにも既に似たようなルールがあることを教えてやってんだよ。わかる?
お前のレスの意味不明さが。
次はせめて中学校卒業してからレスしてな。
214:デフォルトの名無しさん
07/11/21 00:31:15
インデントは・・・
215:デフォルトの名無しさん
07/11/21 00:33:40
インデントはとても合理的だけど、
ブレースによる制御構造も混在しててもいいんじゃないかと思う。
216:デフォルトの名無しさん
07/11/21 00:41:45
>>213
イタタタタ(wwwwwwwwwwwwww
217:デフォルトの名無しさん
07/11/21 04:22:38
関数の右とかifやwhileの右とかの「:」も知らなきゃ書けん罠
218:デフォルトの名無しさん
07/11/21 07:43:36
>>213
Java系言語一つでも知ってたら、 self.foo を見て、これは this.foo だと気づく。
@foo を見ても判らんだろ?
self.__foo を見て、private変数だと判らなくてもプログラム読めるだろ?
しかも、なんとなく他人が気軽に触っちゃいけない雰囲気かもしだしてるだろ?
内包表記も、他の言語で内包表記見たことあるなら一瞬で判るし、
そうでなくても後でリストとして利用している部分を見れば雰囲気で判るはずだ。
それでもって、private変数もリストの内包表記も、使わなくても普通に
プログラム書けるだろ?なら特殊ルール導入しても良いのがPythonic
なんだよ。
論点は特殊ルールの存在自体ではなくて、その特殊ルールを知らなくても
プログラムが読める&使わなくても普通に書けるって事。
219:デフォルトの名無しさん
07/11/21 09:38:00
三行でおk
220:デフォルトの名無しさん
07/11/21 10:55:11
>>218
> Java系言語一つでも知ってたら
メジャーな言語との類似性から来る類推性、分かりやすさ、
習得しやすさおよび学習・移行の容易さを重視するんなら、
現状では好む・好まざるに関わらず、C系のシンタクスがベストだよ。
そういう意味ではself.fooではなくthis.fooのがずっといい。
selfをmeとか書いてもいいなんてのは論外だ。
__init__だの__call__だのが@と大して違いがあるとも思えんな。
単にPerlチックな記法が嫌いなだけじゃないのか。
221:デフォルトの名無しさん
07/11/21 10:59:04
既存の言語に似せていないのに無根拠に「こっちのが分かりやすいだろ」と
Pythonicという名前の宗教を押し売りするんだよねえ
既存のメジャーな言語に似ているものが多くの人にとって読みやすく
理解しやすいことは、自明なわけだが
222:デフォルトの名無しさん
07/11/21 11:06:23
メジャーな言語ってこうですか?わかりません><
<main>
<print>Hello, world!</print>
</main>
223:デフォルトの名無しさん
07/11/21 11:17:36
SGML系はプログラミング言語じゃねえし、
プログラミング言語じゃない言語で一番メジャーなのは英語だろw
224:デフォルトの名無しさん
07/11/21 11:27:21
XSLTはプログラミング言語と言って差し支えない気がする
225:デフォルトの名無しさん
07/11/21 17:26:10
メジャーなのに似てるかとか読みやすいとかどうでもいいが
_と@が同じとか言う奴はヤバい
226:デフォルトの名無しさん
07/11/21 18:22:11
なんか>>218を見て、作って欲しいプログラムの要件を説明するときに
「ここをこうやって (画面の前でぐっと握り拳を握る) ぐーっといろいろやって
(拳に力を込めてゆっくり動かす) ぱーっと結果を出すだけ (力を抜いて掌を開く)
でいいんだけど、簡単にできるよね」
とやってくれたオヤジを思い出した。
いや思いこみはわかるけど、わからんてばw
227:デフォルトの名無しさん
07/11/21 20:29:51
>>220
>__init__だの__call__だのが@と大して違いがあるとも思えんな。
だーかーらー、コンストラクタというものを知っている人なら __init__ を見て
それがコンストラクタだって推測しやすいだろ? @ で何を推測しろと?
228:デフォルトの名無しさん
07/11/21 20:39:27
>>227
コンストラクタならクラスと同名のが多くのプログラマにとっては
分かりやすいに決まってるだろうに
__init__()と__new__()という一見似ているが違うものがあって……なんちゅうことを
何にも知らない奴が読んで「推測」できるかw
229:デフォルトの名無しさん
07/11/21 20:48:21
そもそも、Pythonicってのが宗教だから意味ないと言うのなら、
Perl, Python, Ruby が平行して存在している意味がない。
end がイヤならPythonにすれば良いし、self. がイヤなら Ruby にすれば良いし、
どっちもイヤなら自分で新しい言語作ればいい。
230:デフォルトの名無しさん
07/11/21 21:03:18
>>228
そこまで細かい部分推測しなくても読めるじゃん。
__new__知らなくてもクラス書けるじゃん。
クラスもオブジェクトな言語でコンストラクタをクラス名と同じにすると、
クラス名が変わったときにコンストラクタで混乱するじゃん。
それに、他の言語のマネルールをいろんな言語から持ってきたら結局
判りにくくなる。それなら最初からC++なりJava使えば良い。
__init__とか__call__とか、言語にとって特殊な意味のある名前は__foo__の
形をしているというメタルールを一つ導入するだけで、覚えないと
いけない予約語を大幅に減らせる。
231:デフォルトの名無しさん
07/11/21 22:14:35
んだから、__fooだの__bar__だのの意味、あんたの言うメタルールは、
教わらなきゃわからんだろ
@と何の違いがあるんだ?
232:デフォルトの名無しさん
07/11/21 22:28:05
>>225
>_と@が同じとか言う奴はヤバい
激しく同意。まったく意味不明。
233:デフォルトの名無しさん
07/11/21 23:10:33
>>221
メジャーな言語に似せるつもりならインデントなんてやらねーよ。
234:デフォルトの名無しさん
07/11/21 23:25:43
#!/bin/env ruby
def class Hage
fuga = 2
def hoge
fuga = 1
end
def hige
p fuga
end
end
h = Hage
h.hige
f = Hage
f.hoge
f.hige
235:デフォルトの名無しさん
07/11/21 23:41:06
Ruby って色んな所で躓くよな
まったく初心者向けじゃない
236:デフォルトの名無しさん
07/11/21 23:48:42
RubyのことはRubyのスレでやっとくれ
237:デフォルトの名無しさん
07/11/25 15:08:57
しばらくぶりに来てみたらスレが伸びてるw
238:デフォルトの名無しさん
07/11/25 19:47:32
>>231
こういうやつは、マニュアルとかは読まないで全て始めるのか?
分かんないもの出てくりゃ調べればいいじゃん。
自分が最初にPythonの__やRubyの@に馴染めませんでしたって、
過去の恥を晒してるだけじゃん。
239:デフォルトの名無しさん
07/11/25 20:09:43
バカがいるとスレが伸びる(wwwww
バカが居なくなったからスレが沈静化した(wwwwwwwwwwwwwwwwwwwwwwww
240:デフォルトの名無しさん
07/11/25 22:36:44
延ばすな馬鹿
241:デフォルトの名無しさん
07/11/29 23:57:38
止まっちゃった・・・
242:デフォルトの名無しさん
07/12/01 00:09:47
本当に止まっちゃったね。
インデントについての話じゃなく、selfの是非とか話題がそれると盛り上がるところを見ると、
Pythonのインデントによる制御構造って言うほど悪くないんじゃない?どっかの専門家が
言った意見を素人がそのまま自分の意見として言っているようにしか感じないね。
243:デフォルトの名無しさん
07/12/01 00:42:40
慣れの問題でしかないからな
要は構造が示せればいいだけなわけだし
括弧でもインデントでもフローチャートでも
インデント使うと括弧の対応を自動でチェックしたりしてくれない
素のエディタでもさほど問題にならない、程度の事じゃないかな
244:デフォルトの名無しさん
07/12/01 06:12:37
実際 Python 使ってみると
インデント崩れで起こるトラブルよりも
それ以外の原因でいっぱいトラブルからなぁ
245:デフォルトの名無しさん
07/12/01 08:13:34
>>244
ウンウン、頭が悪いといろいろ大変だよね。
246:デフォルトの名無しさん
07/12/01 09:28:34
一番トラブルのはcopy忘れだな
247:デフォルトの名無しさん
07/12/02 01:06:30
悪くはないけど良いとも思わないってのが正直なところ
実際にはどうでもいい
248:デフォルトの名無しさん
07/12/02 01:17:37
インデントは全然苦にならないんだけど式と文が区別されてて
代入したものをすぐ次の用途に使うときとかに面倒なのが気になる
249:デフォルトの名無しさん
07/12/02 09:29:59
>>248
>代入したものをすぐ次の用途に使うときとか
そんなuglyなコードを書く人とは一緒に仕事したくありませんね。
250:デフォルトの名無しさん
07/12/02 09:50:37
一度代入したら十年は寝かさないとね
251:デフォルトの名無しさん
07/12/02 10:03:28
そうじゃなくてさ。
たとえば、代入と評価は分けて書いた方がいいよね。
252:デフォルトの名無しさん
07/12/02 10:18:16
おめーの次のセリフはこうだ
「ワンライナーを侮辱するなJOJO」
253:デフォルトの名無しさん
07/12/03 23:37:47
ワンライナーを侮辱するなJOJO!・・・ハッ!
254:デフォルトの名無しさん
07/12/04 10:05:16
どうも。インデントは、どうせ言われなくてもやるから、それほどは
違和感を感じてない初心者です。
でも文法的にインデントをブロックの識別に利用しているのなら、
IF 文の末尾に : (コロン) を付けなくても、次の行がインデントして
るならブロック開始なんだから : はいらない子なんじゃないの?
……という疑問が拭えません。
どうして : があるのか、どなたかすっきりさせてください。
255:デフォルトの名無しさん
07/12/04 10:11:15
if condition == True: break;
みたいな書き方をしたい場合はある。こういう場合はコロンがないと超不便。
256:デフォルトの名無しさん
07/12/04 10:29:49
でもそれは : じゃなくて ; でも同じだからな
次の行に回した時にも省略できない理由にはならないし
257:デフォルトの名無しさん
07/12/04 11:43:00
必要か必要でないかだけを言えば必要ない。
でもこの二元論は、
forいらねwhileだけでいいだろとか、
他の言語いらね真のプログラミング言語Lispが既にあるとか(w
そういうたぐいのものに近い。
コロンが使われている理由を探すとすれば、
ABC言語の影響を受けているというのと、ある方が見やすいだろっていう辺りになる。
URLリンク(mail.python.org)
258:デフォルトの名無しさん
07/12/04 21:07:17
コロンが付いている理由はエディッタのオートインデントの実装が楽だからだと Guido がどっかで言ってた記憶が
259:デフォルトの名無しさん
07/12/04 21:07:39
if の : はなんとか納得できるんだけど
else の : はなくてもいいような気がする
260:デフォルトの名無しさん
07/12/04 21:15:38
あーその話で思い出したけど、
forにelse使えるなんて、最初何かの間違いかと思ったよ
261:デフォルトの名無しさん
07/12/04 21:20:26
>>257
>forいらねwhileだけでいいだろとか、
>他の言語いらね真のプログラミング言語Lispが既にあるとか(w
小さい悩みだなw
そんな事言われて気にしてるなよ…
262:デフォルトの名無しさん
07/12/04 21:23:27
>>260
forとかwhileを抜けたあとで
全部の要素ループして抜けたのか
途中で中断して抜けたのか
知りたいときって結構あるんだよね
Pythonは痒いところに手が届きますな
263:デフォルトの名無しさん
07/12/05 01:18:44
>>262
>Pythonは痒いところに手が届きますな
細かいところまで練られている感じがするよね。
Pythonの良いところだと思う。
264:254
07/12/05 09:43:14
>>255
そういう書き方が出来なくても、Python 的には困らない気がします。
>>257
良いポインタの紹介ありがとうございます。やはり冗長だと思ってる
人はいるのですね。
それにしても、キータイプ数を減らすのではなく、冗長性を減らすの
でもなく、見易さを求めるのが Pythonic ってことなんだと受け取って
よいのでしょうか。
Python を触り始めて、面白いとは思っていますが、そのコンセプトが
まだ掴めなくて……ちょっともどかしいカンジの初心者です。
265:デフォルトの名無しさん
07/12/05 11:10:26
悟れ。
266:デフォルトの名無しさん
07/12/05 13:18:56
import this
267:デフォルトの名無しさん
07/12/05 21:51:41
かゆい所に手が届くくらい練られてるならswitchを作れ!
手が届く範囲だけ痒いって言ってるだけだろ自己満足だ!
268:デフォルトの名無しさん
07/12/05 22:10:29
switchはelseifで大抵代用可能だが
elseifはswitchで代用不可能なケースが多い
269:デフォルトの名無しさん
07/12/05 22:45:56
>>267
目の玉がかゆいのなら
目の玉を取り出さないと掻けないぞ(wwwwwwwww
270:デフォルトの名無しさん
07/12/05 22:49:44
これか
URLリンク(ja.wikipedia.org)
271:デフォルトの名無しさん
07/12/06 12:32:15
:が見やすいかどうかはフォントによるな。
次はエディタのフォントも言語仕様になるのかな。
272:デフォルトの名無しさん
07/12/06 12:42:02
>>268
代用できるっちゃできるが、
if c == 1:
elif c == 2:
elif c == 3:
とかいうif~elifの羅列は、switchのほうがずっと綺麗に書けるでしょ。
if~elifだと、変数名を変えたら分岐の数だけ直さなければならなくなる。
「他で代用できるものは要らない」と言うのなら、Pythonは要らないものだらけだよ。
273:デフォルトの名無しさん
07/12/06 12:53:00
Pythonっていろいろ理由付けてるけど、
最終的にはGuidoの好みだからなぁ。
まともに反論してると馬鹿を見る
274:デフォルトの名無しさん
07/12/06 13:47:59
>>272
それをswitchで書き換えてずっと綺麗になった!と言うのはセンスを疑う
275:デフォルトの名無しさん
07/12/06 13:48:20
>>271
>次はエディタのフォントも言語仕様になるのかな。
なるわけないだろバカじゃね???(wwwwwwwwwwwwwwwwww
276:デフォルトの名無しさん
07/12/06 14:07:44
>>272
> 変数名を変えたら
そういう状況は、分岐の形式以前の問題になると思う
277:デフォルトの名無しさん
07/12/06 16:10:05
>>273
ソースが公開されているんだし、作者の意向に反してこうした方が良いと思える点があるんなら、自分で改良すればいいんじゃないかな?
278:デフォルトの名無しさん
07/12/06 22:58:53
>>277
それならPythonベースにする必要はないんじゃないかな?
十分ストレスがない言語が別にあればそれを使えばいいんじゃないかな?
279:デフォルトの名無しさん
07/12/06 23:06:48
>>274
まぁ結局センスの問題だわな
280:デフォルトの名無しさん
07/12/06 23:08:23
たいてい
if c == 1:
elif c >= 2 and c <= 8:
elif c == 9:
みたいな使い方することの方が多いからなぁ
rubyのswitchはそれが出来るけど
281:デフォルトの名無しさん
07/12/06 23:24:01
>>273
>Pythonっていろいろ理由付けてるけど、
>最終的にはGuidoの好みだからなぁ。
Guidoの理由付けに反論できるくらいなら、
Pythonを越える言語をデザインできるセンスがあるってことだと思う。
せいぜいがんばって。
282:デフォルトの名無しさん
07/12/07 00:10:50
それくらいは割と誰でも出来そうだな。
その後のモチベーションをキープするのが一番面倒なんだよ。
283:デフォルトの名無しさん
07/12/07 00:23:39
安奈お前の愛の火はまだ燃えているかい
284:デフォルトの名無しさん
07/12/07 01:04:58
>>280
それがswitchでできてもswitchの意味ないわな。
285:デフォルトの名無しさん
07/12/07 04:14:01
if c == 1:
elif c == 2:
elif c == 3:
これってかなりダサいプログラムだよ
普通は関数テーブル作ってcでdispatchだろ
286:デフォルトの名無しさん
07/12/07 08:06:57
エディタのマクロに「行末セミコロンの後はアウトデント」という俺ルールを仕込んでみた
287:デフォルトの名無しさん
07/12/07 08:53:31
じゃあpassのあとに(ry
288:デフォルトの名無しさん
07/12/07 09:33:09
じゃあオレは
セミコロンキーに改行+アウトデントを割り当てときますね
289:デフォルトの名無しさん
07/12/07 10:09:41
>>282
>それくらいは割と誰でも出来そうだな。
がんばって俺言語作れよ。
言いっぱなしは と て も 恥ずかしいぞ(www
290:デフォルトの名無しさん
07/12/07 12:08:50
>>289
恥ずかしいのはお前だよ。本当に丸出しだな。
そんなの大抵のプログラマなら一度は通る道だぜ。
291:デフォルトの名無しさん
07/12/07 12:21:53
というか、俺言語を作った事が無いプログラマってそんなに多いのか?
292:デフォルトの名無しさん
07/12/07 12:43:08
俺言語を作っても、多くの人に受け入れられるものは少ないんじゃない?それができるのならRubyやPythonの開発者のように、それで食っていけるだろうし。
まぁ、できなくてもプログラマとして食ってるヤツは嫌というほど見てきたし、そんなムキになるほどのことでもないような気がするんだけど。ボクはできない方だな (自爆)
293:デフォルトの名無しさん
07/12/07 12:56:52
> それで食っていけるだろうし
えっ、他の仕事もしてるんじゃないの?
294:デフォルトの名無しさん
07/12/07 13:13:43
ぼくちんはただいまヒキコモリちうなんですが、
ぱいそんをべんきょうしているので
いずれはGoogleにはいって、
いちねんくらいでいっしょうつかいきれないくらいのおカネをかせぐつもりでいます!!!
こんなぼくちんをおうえんしてくださいね!!!!!!
295:デフォルトの名無しさん
07/12/07 14:05:11
> えっ、他の仕事もしてるんじゃないの?
「それで食っていける」と「それだけで食っていける」は意味が違うと思います。
296:デフォルトの名無しさん
07/12/07 16:20:46
Pythonに文句あるなら俺言語作れw
297:デフォルトの名無しさん
07/12/07 16:30:32
>>292
この流れでは多くの人に受け入れられるかどうかは話してないだろう。
ユーザ多い=良いとか言ってる奴はPerlあたりの真似しまくって結果Perl以下になって
売りは日本製だけ~みたいなもん平気でつくりそうだ
あとユーザ数で語るならRubyじゃなくてPerlを出さないとお里が知れちゃうゾ懿」�
298:デフォルトの名無しさん
07/12/07 18:32:33
俺言語の話になってることがアホすぎwww
299:デフォルトの名無しさん
07/12/07 19:29:16
>>295
この場合は、
「それで食っていける」=「それで食えるだけの収入がある」=「それだけで食っていける」
じゃないか?
300:デフォルトの名無しさん
07/12/07 21:33:16
switch文でbreak無しのcaseで制御が下に落ちていくようなのは
どうやってelseifで書くの?どうせそんな糞プログラム書くなとか
言って正当化されるのがオチだろうけど!
301:デフォルトの名無しさん
07/12/07 21:34:21
>>293
「それだけで食っていける」!=「その仕事しかしていない」
じゃないかな?
302:デフォルトの名無しさん
07/12/07 22:21:28
>>300
if hoge == 1:
HOGE
elif hoge == 2:
FUGA
elif hoge == 3 OR hoge == 2:
if shine:
SHINE
else:
IKIRO
else:
ORZ
303:デフォルトの名無しさん
07/12/07 22:29:45
>>300
if case1:
CASE1
if case2:
CASE2
if case3:
CASE3
...
ということじゃなくて?
304:デフォルトの名無しさん
07/12/07 23:31:44
>300
結局その記法ってバグなのか意図なのかが
分かりにくくなることが多いし
できるようにするメリットが少ないって判断じゃなかったか?
305:デフォルトの名無しさん
07/12/07 23:34:17
>>303
いや、いちいち break で脱出するコードにしないと次の case もそのまま
実行される仕様の糞言語があるんだ
306:デフォルトの名無しさん
07/12/08 01:15:59
>>300はアレだが>>302もちょっとどうかと思うのは俺だけではないはずだ
307:デフォルトの名無しさん
07/12/08 01:30:55
>>302
それで納得できるのかお前は
308:デフォルトの名無しさん
07/12/08 03:02:42
やっぱRubyだな
309:デフォルトの名無しさん
07/12/08 03:36:02
このタイミングでこういうコメントを入れるから、「こういう書き方もできます」というシンタックスシュガーに踊らされてばかりで
きちんとしたドキュメントも書けない上に、生産性がないのが日本のRubyユーザだと思われるんじゃないかな?
310:デフォルトの名無しさん
07/12/08 08:39:02
Rubyはソースがドキュントだからってことになってるからなぁ
生産性も糞もないよなぁ
311:デフォルトの名無しさん
07/12/08 09:40:24
趣味で作ったプログラムを
1年以上経ってからも
保守する気になる言語
ソレがPythonだっただけだ
312:デフォルトの名無しさん
07/12/08 10:05:22
どの言語で書いても保守する気になるけど?
313:デフォルトの名無しさん
07/12/08 10:12:35
俺はドMなのでRubyで小汚く書いたソースコードでも泣きながら保守するぜ!
314:デフォルトの名無しさん
07/12/08 10:25:27
今まで見た中でこれは酷いと思ったのがZopeなんだが・・・・
315:デフォルトの名無しさん
07/12/08 11:23:17
>>310
Rubyの生産性がないと言っているんじゃない。日本のRubyユーザの生産性がないと言っている。
316:デフォルトの名無しさん
07/12/08 11:42:59
python厨って困るとruby叩きに走るよな。
それも必ず「糞」とか「汚い」とかの言葉が入る。
317:デフォルトの名無しさん
07/12/08 12:42:48
>>316
自惚れるなよ
318:デフォルトの名無しさん
07/12/08 13:14:09
Rubyの話題はどうでもよくね?
319:デフォルトの名無しさん
07/12/08 14:13:59
そろそろインデントの話に戻ろうぜ
320:デフォルトの名無しさん
07/12/08 14:32:22
ム板でインデントのないコードを書き込む奴はDQN
それと、全角インデントにする野郎は氏んでいいよ^^
321:デフォルトの名無しさん
07/12/08 14:34:49
>>320
そういう話だっけw
322:デフォルトの名無しさん
07/12/08 14:35:52
それは、行頭の空白文字列を nbsp に変更するプログラムを
Python と Ruby と Haskell で書いて比較するというお題と
考えてよろしいかな?
↓じゃあ、まず Python から
323:デフォルトの名無しさん
07/12/08 15:46:07
しーん。。。
324:デフォルトの名無しさん
07/12/08 15:54:58
s/^[ ]*/ /g
325:デフォルトの名無しさん
07/12/08 16:39:31
話しそれるけど、これって行頭だけでなく全部やっちゃってOKじゃね?
326:デフォルトの名無しさん
07/12/08 16:43:54
>>324
TAB は良いんだっけ?
327:デフォルトの名無しさん
07/12/08 16:53:37
>>326
その前にスペース4個でも8個でも1個の になるって問題点が>>324にはあるぞ
328:デフォルトの名無しさん
07/12/08 16:53:52
お楽しみ中のところ申し訳ないが
ソースを追試する側としては迷惑だからやめてくれ
半角空白でも画面に出ないだけでデータは残ってるから
こぴぺするだけで直るんだが
にされると復元操作が必要になる
復元プログラムをセットで提示してもらわにゃ
329:デフォルトの名無しさん
07/12/08 18:06:47
ほえ?
330:デフォルトの名無しさん
07/12/08 21:20:23
>>328のコピペ環境
< → <
> → >
& → &
→ (←何故か変換されない)
331:デフォルトの名無しさん
07/12/09 03:06:42
かちゅーしゃ使ってると、全角インデントが一番読みやすいんだけど
332:デフォルトの名無しさん
07/12/09 03:08:12
>>324は[ ]*が0回以上の繰り返しだから結論としてインデント消えてないか?
あと、キャレット付いてるからgオプション意味ない
333:デフォルトの名無しさん
07/12/09 03:09:39
>>332
いろいろ間違ってる
334:デフォルトの名無しさん
07/12/09 03:22:36
>>271
3.0でバッククオートがなくなる理由は`フォントによっては見づらいから`らしい
335:デフォルトの名無しさん
07/12/09 03:35:15
>>334
フォント、マジだったのかwwww
確かにそこは見にくいことがあるw
336:デフォルトの名無しさん
07/12/09 03:46:38
>>333
うちの環境のsedで試したところ、インデント消えて一律行頭&nbsp;になったけど?
ただし&をエスケープする必要があったけど
337:デフォルトの名無しさん
07/12/09 03:52:26
>>336
sed知らんがな。
結果うp。
338:デフォルトの名無しさん
07/12/09 12:28:44
>>332,336
すまん。酔っぱらって勘違いしてた。
339:デフォルトの名無しさん
07/12/24 01:15:37
self 論議乗り遅れた('A`)
Pythonじゃなくて失礼。
Delphi だと、Selfはかけるけど、with Hoge do 内くらいしか使わないんだよね。
Pythonみたいに、宣言が必要ない言語だと、Self相当は必須なんだね。
よくわかった。
とはいえ、Self必須は面倒だな。
スクリプト言語なのに字数が明らかに多くなる・・・。(perlみたいなのも勘弁だが)
わかりやすい点がいいけどさ・・・
:のつけ時は、いっつも、忘れてわからなくなる。
340:デフォルトの名無しさん
07/12/24 01:31:57
>>3
($#9737◇$#9737)∑
341:デフォルトの名無しさん
07/12/24 01:32:44
$#9737;
342:デフォルトの名無しさん
07/12/24 08:54:54
selfやな奴は普通に s とか _ とか使えば良いと思う。
とくに、人が書き足したりするようなコードでなければ、好き勝手書けば良いと思う。
343:デフォルトの名無しさん
07/12/24 22:37:26
>>342
それじゃあインデントでわざわざ記法を強制するような
Pythonの思想に反するんじゃね??なんでもいいなら
そもそもインデントだっていらなくね?
344:デフォルトの名無しさん
07/12/24 22:39:38
凄い論理だ
345:デフォルトの名無しさん
07/12/24 23:08:44
>>339
何か勘違いしてるような…。
使う使わないは兎も角、大概のOOPLにおいて
self や this みたいな「自身」を参照するものは
何らかの形で存在してる。
Pythonの場合の self 議論は
「メソッドの仮引数に self を明示的に書かなければならない」
ってところじゃないかと。
346:デフォルトの名無しさん
07/12/24 23:12:56
だから "書けば" それでいいじゃん
.... 終了
347:デフォルトの名無しさん
07/12/25 01:21:10
WindowsAPI
hoge(hWnd, xxx);
fuga(hWnd, yyy);
348:デフォルトの名無しさん
07/12/25 01:45:19
それはハンドル
そしてAPIは言語じゃない
349:デフォルトの名無しさん
07/12/25 04:45:10
WindowsAPIは、C言語レベルのAPIだからな。
ハンドル≒OOPのインスタンス=self という解釈なら正しいが、
そうすると、Python が、C言語レ(ry
350:デフォルトの名無しさん
07/12/25 05:50:23
タイトル:Pythonに見られるインデントによる制御構造の是非
【糞スレランク:D】
直接的な誹謗中傷:0/349 (0.00%)
間接的な誹謗中傷:19/349 (5.44%)
卑猥な表現:2/349 (0.57%)
差別的表現:16/349 (4.58%)
無駄な改行:0/349 (0.00%)
巨大なAAなど:16/349 (4.58%)
同一文章の反復:1/349 (0.29%)
by 糞スレチェッカー Ver1.12 URLリンク(kabu.tm.land.to)
Dって微妙だな・・
351:デフォルトの名無しさん
07/12/25 10:38:10
巨大なAAなど:16/349 (4.58%) ってソースコード貼り付けが誤判定されてる気がする
352:デフォルトの名無しさん
07/12/25 22:01:58
タイトル:Pythonのお勉強 Part22
【糞スレランク:E】
直接的な誹謗中傷:0/488 (0.00%)
間接的な誹謗中傷:11/488 (2.25%)
卑猥な表現:8/488 (1.64%)
差別的表現:1/488 (0.20%)
無駄な改行:0/488 (0.00%)
巨大なAAなど:6/488 (1.23%)
同一文章の反復:2/488 (0.41%)
by 糞スレチェッカー Ver1.12 URLリンク(kabu.tm.land.to)
353:デフォルトの名無しさん
07/12/25 22:07:42
>>352
またひとつ糞レスをつけおって・・・
354:デフォルトの名無しさん
07/12/25 22:28:04
if hoge == fuga:
HOGE
else:
FUGA
if hoge == fuga: HOGE
else: FUGA
if hoge == fuga:
HOGE
elsif hoge == hemi:
FUGA
else:
HEMI
if hoge == fuga: HOGE
elsif hoge == hemi: FUGA
else: HEMI
355:デフォルトの名無しさん
07/12/27 02:28:13
結局インデントでブロック指定するのは
たいして利点は無くて欠点が大きいでOK?
356:デフォルトの名無しさん
07/12/27 06:10:08
欠点が無くて利点が大きい
357:デフォルトの名無しさん
07/12/27 06:44:11
ONE WORD, FORCED INDENTATION OF THE CODE, THREAD OVER!!!!!!!!!!!!!!!!!!!
358:デフォルトの名無しさん
07/12/27 09:11:04
インデントはともかくとして
pythonで書くとコードが綺麗になるのが好き
359:デフォルトの名無しさん
07/12/27 21:12:06
言語仕様に頼らないときれいなコードを書けないおとこの人って・・・
360:デフォルトの名無しさん
07/12/27 23:23:04
そうだね。Perl使いはみんな綺麗なコードを書くよね。
361:デフォルトの名無しさん
07/12/28 03:39:25
インデント否定派の人はエディターで自動ディデントできないからって言うのが主な理由?
362:デフォルトの名無しさん
07/12/28 09:38:20
ディデントって何?
ポリデントみたいな物か?
363:デフォルトの名無しさん
07/12/28 09:47:07
インデントの逆
364:デフォルトの名無しさん
07/12/28 10:53:19
アウトデント?
オフデント
バックデント
モドリデント
365:デフォルトの名無しさん
07/12/28 10:57:03
デデンドモリ
366:デフォルトの名無しさん
07/12/28 14:44:59
マジレスするとアンインデントだろ
367:デフォルトの名無しさん
07/12/28 14:59:26
>>359
誰が書いてもある程度読みやすくなるようにできているのだよ。つまり、書き手よりも読み手を
重視しているんじゃねぇの? (でも、インデントの階層が深くなると、書いていて分かりづらく
なってくる。それも狙いかもしれんが。)
368:デフォルトの名無しさん
07/12/28 16:13:28
>でも、インデントの階層が深くなると、
それは他の言語でも基本的には同じ問題で
そうなったら大抵は何か考え直すべきとされてるでそ
369:デフォルトの名無しさん
07/12/28 16:37:37
Pythonもいろいろ工夫してるけど
へぼが書くとやっぱり読みにくい
370:デフォルトの名無しさん
07/12/28 19:38:58
>>367
そんなに強制したいなら変数の命名規則も強制しろ。
そして変数の名前から型が決まるようにすればいい。
371:デフォルトの名無しさん
07/12/28 20:59:40
つまり「ネストの深さ」にも「暗黙の制限」が
かかっているような言語仕様なんですね。
いくらでも深くネストできるけど、やりすぎちゃダメ!という…
372:デフォルトの名無しさん
07/12/28 21:00:27
つシステムハンガリアン
373:デフォルトの名無しさん
07/12/28 21:31:40
>>362>>364>>366
URLリンク(www.python.jp)
この説明ではdedentと言ってる
374:デフォルトの名無しさん
07/12/28 21:50:46
ついでに関数とかメソッドとかブロックの中の行数も制限しようぜ。
5行以内に。
375:デフォルトの名無しさん
07/12/28 22:27:39
「強制すんな!おれは空白を何個入れるかで自己表現してんだ!」って思うか
「これでアホのゴミネストに付き合わなくてすむぜ」って思うかで
プログラマとしての何かが問われるだろう
376:デフォルトの名無しさん
07/12/28 22:45:40
>>370
そんなの強制しなくても命名規則を決めればいいだけ
従わないヤツはチームから除外すれば済むし
それくらいできないヤツはどうせダメなヤツだから
むしろ除外した方がチームのため
377:デフォルトの名無しさん
07/12/28 23:06:19
>>376
だよな。インデントだってコーディングルールを強制すればよいだけで
従わないやつは排除すればいい。インデントを言語仕様で強制する必用
全然ねえよな。Pythonのインデントに関する理屈は屁理屈
378:デフォルトの名無しさん
07/12/28 23:10:52
>>377
>インデントだってコーディングルールを強制すればよいだけで
そうそう。
インデントを廃止するかわりに,ブラケットやendみたいなキーワードを導入すればいいだけの話だよね。
簡単簡単。
379:デフォルトの名無しさん
07/12/29 01:18:06
ブラケットやendみたいなキーワードを強制されるのは嫌だな
380:デフォルトの名無しさん
07/12/29 01:28:23
Ruby書いてるときに
def range(start, end)
..
って書けないのはちょっといやだな
381:デフォルトの名無しさん
07/12/29 01:30:05
ブラケットがキーワードなのか
382:デフォルトの名無しさん
07/12/29 01:50:36
>>375
どちらもアホプログラマにしか思えない
383:デフォルトの名無しさん
07/12/29 02:12:48
自分たちがちゃんとインデントされてるコードを書いてるかどうかという話と
言語仕様としてインデントでブロックをあらわすということは何の関係も無いわけだけど
>>377と>>378は何を言ってるんだ?完璧に意味不明
384:デフォルトの名無しさん
07/12/29 07:19:11
378は皮肉だろ。多分
385:デフォルトの名無しさん
07/12/29 09:31:12
・378を皮肉だと分からないヤツ
・「キーワード」が「ブラケット」と「end」にかかっていると思っちゃうヤツ
どっちもPythonistaとして失格。
Monty Pythonでも見ながら基本からやり直した方がいい。
386:デフォルトの名無しさん
07/12/29 10:32:26
>>379
Python でもかけませんがあにか
387:デフォルトの名無しさん
07/12/29 10:38:33
>>385
別にPythonistaとやらになりたくはないがな
静的スコープのない言語なんて願い下げ
388:デフォルトの名無しさん
07/12/29 10:53:07
Pythonは思いっきり静的スコープを採用した言語だが…
389:デフォルトの名無しさん
07/12/29 14:06:52
まぁ378は皮肉としてはどうかと思うが
390:デフォルトの名無しさん
07/12/29 14:12:36
そんなこといったら、>>383のもわかってる煽りだろw
391:デフォルトの名無しさん
07/12/29 14:43:48
>>383に食いつくのはプライドが許さない
392:デフォルトの名無しさん
07/12/29 20:17:51
>>386
これできみはしやわせになれると思うよ。
end = 1
393:デフォルトの名無しさん
07/12/29 20:22:38
389=391はおれげんごをつくった。
でもだれもつかわなかった。
394:デフォルトの名無しさん
07/12/30 00:28:21
そうですか
395:デフォルトの名無しさん
07/12/31 12:26:33
そうです
396:デフォルトの名無しさん
08/01/01 07:34:26
おめでとうございます
397:デフォルトの名無しさん
08/01/04 23:16:45
end があると、endだけの行が大量に発生するのが、コードが間延びしてる感じがしてダサい
pythonの方がエディタで眺めたときに、均等に情報が並んでる感じがして気持ちいい
398:デフォルトの名無しさん
08/01/05 04:29:54
Pythonだとここまでで、インデント終わりってのが明確にわからないのだが、
その辺、どうやってみわけるの?
399:デフォルトの名無しさん
08/01/05 07:25:06
>>398
次の命令のインデントでわかる。
インタラクティブモードの場合は空行を入れることでも可。
400:デフォルトの名無しさん
08/01/05 16:34:08
>>399
やっぱそうか・・・
エディタとかブラウザで、どこまでスクロールすればいいんだろとか不安になるもんで
401:デフォルトの名無しさん
08/01/05 18:18:36
why?
kwsk
402:デフォルトの名無しさん
08/01/05 18:50:31
要するに「ブロック終了」に相当する単語なり文字が目に見えないから不安な気がするってことじゃないか?
自分もpythonはじめたかなり最初の方はそういう感覚があったような気がする
403:デフォルトの名無しさん
08/01/05 20:41:45
こういうコードに遭遇すると殺意沸くよね
def ふにゃふにゃ
ぴっぽろ
ぱっぽろ
# 以下不要なのでコメントアウト
# ぷんぱか
# ほにゃらら
(20行続く)
# 2008/1/5 追加しました。
return "こんなところにこんなものが!”
404:デフォルトの名無しさん
08/01/05 20:51:11
それはPythonに限らないだろ
String ふにゃふにゃ() {
ぴっぽろ;
ぱっぽろ;
// 以下不要なのでコメントアウト
// ぷんぱか;
// ほにゃらら;
(20行続く)
// 2008/1/5 追加しました。
return "こんなところにこんなものが!";
}
405:デフォルトの名無しさん
08/01/05 21:30:30
いや、ちがうんだけど、
なんだかとても眠いので寝る。
続きは夢の中で議論しましょう。
406:デフォルトの名無しさん
08/01/05 22:26:02
じゃ、そうしましょう。
おやすみなさい。
407:デフォルトの名無しさん
08/01/06 00:00:56
俺も夢の中で、まってます
408:デフォルトの名無しさん
08/01/06 01:05:14
じゃあ俺はニシキヘビを持って行くね。
409:デフォルトの名無しさん
08/01/06 13:23:26
なんで来なかったんだよ!
410:デフォルトの名無しさん
08/01/06 13:30:56
ごめん、熟睡しちゃった。テヘ
411:デフォルトの名無しさん
08/01/06 15:01:51
寝て起きたらやり合うのめんどくさくなった
412:デフォルトの名無しさん
08/01/06 17:03:06
Pythonの場合、ブロックを跨いだ場所にカット&ペーストしたら
必ず自分でインデント調整せないかんの?
自動整形とか出来なさそう…まぁ、そういう機能ないエディタだと普段やってることだけどさ
413:デフォルトの名無しさん
08/01/06 18:28:56
ブロックを跨いでるなら自動整形出来るだろ
414:デフォルトの名無しさん
08/01/06 19:24:27
インデント調整ってめんどくさくないんだよ!
415:デフォルトの名無しさん
08/01/06 19:30:36
>>412
>Pythonの場合、ブロックを跨いだ場所にカット&ペーストしたら
>必ず自分でインデント調整せないかんの?
そういう場合、ブロックを関数とかメソッドとかに出来るし
何の関係も無い
カット&ペーストしたら大抵は何か考え直すべき
へぼが書くとやっぱり読みにくい
416:デフォルトの名無しさん
08/01/07 08:15:19
考え直して関数・メソッドにする時にカット&ペーストしない?
417:実際に書いたことあれば疑問に思わないんだけどね
08/01/07 10:42:03
ブロックごとペースとしたらそのブロック全体の
インデントをちょちょいと直せばいいだけ
直すインデントの量は先頭を見れば自明
何か疑問でも?
418:デフォルトの名無しさん
08/01/07 10:49:10
dakara sorega mendou datte hanasi dattandaro
419:デフォルトの名無しさん
08/01/07 10:51:54
ペーストした時点で正しいコードになってるのと
ペースト後インデント直さないと正しいコードにならないのとの違いの話だな
420:デフォルトの名無しさん
08/01/07 10:58:26
めんどうじゃないよ
421:デフォルトの名無しさん
08/01/07 11:41:19
めんどうだよ
422:デフォルトの名無しさん
08/01/07 12:27:11
めんどうじゃよ
423:デフォルトの名無しさん
08/01/07 12:31:50
めんどうでござる
424:デフォルトの名無しさん
08/01/07 12:32:58
めんどうだったら
425:デフォルトの名無しさん
08/01/07 13:18:51
めんどうなんだからねっ
426:デフォルトの名無しさん
08/01/07 13:20:16
カッコで照合する言語の場合は尻尾のカッコの数を間違えて
整合性がとれなくなったりコードがおかしくなったりするわけだけど
その際の確認の手間がペーストよりも後ろ側に来てるだけ
面倒もへったくれもないし議論になってねーっつーの
427:デフォルトの名無しさん
08/01/07 13:28:32
カッコの数を間違えたらSyntax Erorrだと思うが
428:デフォルトの名無しさん
08/01/07 15:23:17
Pythonもブロックのインデントレベルが違うと構文エラー
大らかなのはアセンブラぐらいかな
429:デフォルトの名無しさん
08/01/07 15:43:28
何言ってんの?
430:デフォルトの名無しさん
08/01/07 17:19:08
Python でインデントレベルが変わるのは : の次と
戻す時だけだから他言語での括弧の不整合と同じく
エラーが出るね
431:デフォルトの名無しさん
08/01/07 17:48:15
よく考えろよ。
432:デフォルトの名無しさん
08/01/07 18:23:20
お金は大事だぞ
433:デフォルトの名無しさん
08/01/07 18:53:07
あふぉらっく
434:デフォルトの名無しさん
08/01/07 21:00:00
python 書いたことある人間がうだうだ言うのはともかく
全く書いたり試したりしないで
脳内でイチャモン生成されても的外れだってことさ
435:デフォルトの名無しさん
08/01/07 22:00:38
ていうかエラーが出ない人為的なミスに関して話をしてたのに
なんで「エラーが出る状況ではエラーがでるから同じだなんて」
って話になってるの?
436:デフォルトの名無しさん
08/01/07 23:38:37
ネタスレ状態も悪くないと思う俺がいる
437:デフォルトの名無しさん
08/01/08 12:45:19
>435 が思っているのもネタに過ぎないしな
438:デフォルトの名無しさん
08/01/08 15:08:03
そりゃエラーが出ない人為的状況はインデントの有る無しと関係ないから
つまりスレタイ読めという事
439:デフォルトの名無しさん
08/01/08 16:43:39
だからその時のミスを防ぐ手だてとかリカバリーの方法だよ。
カッコとかendとかある言語の方がいろいろ手を打てる。
たいていは自動フォーマッタが視覚的にミスに気づかせてくれる。
インデントとブロックを両方プログラマの手にあずけちゃうと、
プログラマがミスしたときの保険が無くなる。
440:デフォルトの名無しさん
08/01/08 21:11:44
括弧やendの辻褄で自動フォーマッタが気づかせるレベルのエラーなら
Python でもインデントのレベルの辻褄が合わないから同様に気づくと思うが
441:デフォルトの名無しさん
08/01/08 21:17:25
>>440
書き出すインデントのレベルを勘違するのがミスだろ。
既に勘違いしてるのにどうやって辻褄が合わないことに気づくんだよ。
442:デフォルトの名無しさん
08/01/08 22:30:42
if hige:
fuga
fuga
pass
443:デフォルトの名無しさん
08/01/08 22:32:58
んな奴にぬるい気持ちでコピペさせない、が正しい
444:デフォルトの名無しさん
08/01/08 22:50:15
じゃあ熱く「俺にコピペさせてくれ!オゥイェー!ベイベー!」って言われたらどうするんだよ。
445:デフォルトの名無しさん
08/01/08 23:07:35
コードをコピペすんなよキチガイ
446:デフォルトの名無しさん
08/01/08 23:28:17
じゃぁカットアンドペーストにするよ
447:デフォルトの名無しさん
08/01/08 23:54:46
>>446
天才
448:デフォルトの名無しさん
08/01/09 10:28:47
じゃ俺はコードの代わりにコンセントを使うよ
449:デフォルトの名無しさん
08/01/09 19:09:42
【審議中】
_,,..,,,,_ _,,..,,,,_
_,,..,,,_/ ・ω・ヽ/・ω・ ヽ,..,,,,_
./ ・ω_,,..,,,,_ l _,,..,,,,_/ω・ ヽ
| / ・ヽ /・ ヽ l
`'ー--l ll l---‐´
`'ー---‐´`'ー---‐´
450:デフォルトの名無しさん
08/01/15 16:56:52
まずは言語仕様の問題と開発環境の問題を区別しよう。
話はそれからだ。
451:デフォルトの名無しさん
08/01/15 22:41:42
そんなことより449の審議がいつ終わるかのほうが問題だ
452:デフォルトの名無しさん
08/01/15 22:49:01
CM明けなんじゃない?
453:デフォルトの名無しさん
08/01/26 00:00:07
Python 勉強中のヘタレです。
私も昔の >>402 さんのように終了記号が無いのが不安です。
気が緩んでインデントを間違えてしまう
うっかり者は使うな!という言語なんでしょうか…?
前に Python でコード書いてたら、
急に好きなおにゃのこから電話が来て
電話の後インデントしきってないのを忘れて悩みました。
おにゃのこよりインデントを大事にしろ!
おしゃべりしててもインデントを忘れるな!って言語なんでしょうか。
コードを見ていると綺麗だとは思うのですが、
書くときは正しくヘビのように絡み付いて
縛り付けられる感じがして辛いです。
皆さんインデントのミスなんてしないんでしょうか?
ネタじゃなくてホントに。
454:デフォルトの名無しさん
08/01/26 03:26:47
>453
俺は他の言語の出身だが、他でもインデントはキッチリ書くよ。
経験上、そうでないと自分がミスリードするし
インデントをキッチリ書くことは「当たり前のことを当たり前にやってるだけ」と思ってる。
欠点としては、自動整形が効かないってことかな。
場合によってはこれだけが痛い。
455:453
08/01/26 04:14:51
私も普段からインデントはキッチリ書く、
というか書いてないと気がすまないのですが
コードを移動したり、差分をマージする時にドキドキしてしまいます。
マージとか他の言語だと、
ひとまずペーストしてインデント揃えて、ってできるんですが
Python だとペースト~揃える間を一息でやらないと怖くて緊張します。
456:デフォルトの名無しさん
08/01/26 11:29:03
まずアペンドしてからちまちま直せば良いんじゃないだろうか
% cat code01.py >> code00.py
% vi code00.py
457:デフォルトの名無しさん
08/01/27 13:40:14
#{
#}
というインデントのヒントをコードに埋め込めばいいんだよ。
なんという逆転の発想・・・
458:デフォルトの名無しさん
08/01/28 16:35:23
pass でブロック終端を表すのはかったるいとおもったけど、
...(Ellipsis)なら、それほど悪くないかなと思った・・・
459:デフォルトの名無しさん
08/01/28 22:43:30
> pass でブロック終端を表す
そんなことしたっけ?
もしかして、空ブロックの代わりにpassって書くのと勘違いしてる?
460:デフォルトの名無しさん
08/01/28 23:22:31
目印としてってことじゃねーの
461:デフォルトの名無しさん
08/01/29 00:10:41
emacs だと pass の行の次はインデントが強制的に1つ引っ込むんだよ
他のエディタはどうなってるか知らんが
462:デフォルトの名無しさん
08/01/29 06:10:34
それはEmacs特有のサービス(?)だと思うぞ
463:デフォルトの名無しさん
08/01/29 08:46:39
マクロがあればどんなエディタでもできそうな気がする
464:デフォルトの名無しさん
08/01/29 16:19:17
面白い仕掛けだね、pass でインデント終了って
465:デフォルトの名無しさん
08/01/30 03:26:02
do - end
: - pass
文字数は変わらないね
466:デフォルトの名無しさん
08/01/30 03:48:01
pass って書くなら、4回バックスペース押したほうがいいと思う。
つうか、ブロック毎にいちいち pass pass 書いてる python コードなんて
誰も読む気しない
467:デフォルトの名無しさん
08/01/30 07:49:50
passなんて空ブロック以外で見たことないぜ
468:デフォルトの名無しさん
08/01/30 09:47:35
>>467
>>461
設定次第でバックスペースは1回にできそうだな
469:デフォルトの名無しさん
08/01/30 09:54:52
pass じゃなくて1って書けば?
470:デフォルトの名無しさん
08/01/30 15:17:47
>>466
そうじゃなくて、自動整形するためのtipsの話じゃなかったのか?
471:デフォルトの名無しさん
08/01/30 17:50:00
個人的な感想だけど、自動整形なんてほとんど使う機会がないな。
そもそも他のソースからのコピペをする機会が少ない。その必要があるときも
ブロックを指定してインデントなりデデント(IDLE なら Ctrl-[ と Ctrl-])すれば一瞬で済むし。
ぶっちゃけ、453さんみたいに苦痛を感じる人がいるのが不思議。
経験的に言って、Python のコーディングをきちんとサポートしてくれるツールを使えば
インデントに起因する問題は何も起こらないよ。あとは慣れの問題。
472:471
08/01/30 17:55:50
ふと、インデントに過剰反応する人は考えすぎなのかなーとオモタ。
Python のインデントって自転車みたい。
乗れないうちはバランスとか転んだら痛いとかいろいろ考えちゃうけど、それって無駄。
乗れるようになったら意識しなくても快適に乗りこなせるようになる。
473:デフォルトの名無しさん
08/01/30 18:01:49
いや、だから、
いきなり }<改行> を入力すれば、勝手にインデントを1段戻した位置にズレて
次の行ではそのまま書き続けられる位置にカーソルが移るような環境に生きていると、
いちいちインデントを調整しながらコードを書くことが苦痛だと。
そういうことじゃないかと思うわけだけど。
書くコードの種類にもよるとは思うけど。
474:デフォルトの名無しさん
08/01/30 18:14:51
ブレースだろうがインデントだろうがブロックの把握は行わなきゃいけないものだと思うんだが
475:デフォルトの名無しさん
08/01/30 19:43:40
} 入れるのと Backspace 押すのとじゃ手間に大差ない気がするが
476:デフォルトの名無しさん
08/01/30 19:52:09
勝手に動かされるのキライ
477:デフォルトの名無しさん
08/01/30 20:41:12
他人のソース見るときが一番不安
478:471
08/01/30 21:23:09
>>473
> 勝手にインデントを1段戻した位置にズレて
> 次の行ではそのまま書き続けられる位置にカーソルが移るような環境
すくなくとも IDLE や Emacs の Python モードはそういう環境だよ。
if foo is True: [Enter]
で1段インデントされるし
return [Enter]
で1段デデントされる。return, break, continue, pass 等で終わらないブロックの場合は
Backspace の入力が必要だけど、475さんの言うとおり、C 等で } の入力が必要なのと同じ。
そういえば Emacs の C モードで複数行にわたるマクロを書いてて行末の \ が
あるのとないのとで自動インデントの振舞いが変わって難儀するのを思い出した。
あとで \ をつけてそろえようと思ってても、自動インデントで思わぬ位置までカーソルが飛んでいく。
まあ善し悪しだね。万能じゃない。
479:デフォルトの名無しさん
08/01/30 22:18:18
インデントでブロックをあらわすと、最小コストで構造を表現できる。
記号でブロックをあらわすと、プログラマの意図の通りの構造になっているか
ダブルチェックすることができる。
480:デフォルトの名無しさん
08/01/30 22:23:52
記号でブロックをあらわすと、
見た目と意図が激しく乖離するものが出来上がる現実
481:デフォルトの名無しさん
08/01/30 23:32:28
なんで?
482:デフォルトの名無しさん
08/01/31 18:50:03
>480 は初心者にコード書かせた場合の話だろうな。
確かに、ブロックを正しく書く癖を付けさせるなら、こういう言語かも知れない。
483:デフォルトの名無しさん
08/01/31 20:48:36
インデントブロック無しで書きたいときもあるのだ。たとえば
if (hoge) break;
とか。
switch (var) {
case A: hoge(); break;
case B: huge(); break;
case C: huga(); break;
}
とか。
484:デフォルトの名無しさん
08/01/31 23:22:16
if hoge: break
ってあるよ
485:デフォルトの名無しさん
08/02/01 00:42:51
Python に switch はない。
if var==A:
hoge1()
else if var==B:
hoge2()
else if var==C:
hoge3()
もし A,B,C が 0, 1, 2 というふうに序数になっているなら
(hoge1, hoge2, hoge3)[var]()
だな
486:デフォルトの名無しさん
08/02/01 00:43:53
pythonのインデント構造って、エディタからインタプリタにコードをカットアンド
ペーストするとき、すごくやりにくいよね。
前に、プレゼンのビデオでデモをやってる人がいて、
先頭にスペースが入っちゃったりして、やりにくそうだった。
また、インデントの深いところの複数行をまとめてコピーするのは不可能だよね。
487:デフォルトの名無しさん
08/02/01 01:24:58
先頭に、if 1:
とか入れれば、好きな深さのコード実行できる
>>> if 1:
... print 1
... print 2
... print 4
...
1
2
4
488:デフォルトの名無しさん
08/02/01 06:41:17
if var==A:
hoge1(a+b)
else if var==B:
hoge2(c-d)
else if var==C:
hoge3(e/f)
もし A,B,C が 0, 1, 2 というふうに序数になっているなら
(hoge1, hoge2, hoge3)[var]((a+b, c-d, e/f)[var])
ということか
489:デフォルトの名無しさん
08/02/01 06:41:54
副作用ワロスw
490:デフォルトの名無しさん
08/02/01 09:41:51
俺だったらこうかなあ。
def case_A():
hoge1(a+b)
def case_B():
hoge2(c-d)
def case_C():
hoge3(e/f)
f = (case_A, case_B, case_C)[var]
f()
491:デフォルトの名無しさん
08/02/01 09:54:55
> また、インデントの深いところの複数行をまとめてコピーするのは不可能だよね
それはPythonじゃなくてエディタの機能の話だろ。
492:デフォルトの名無しさん
08/02/01 11:00:13
>> 491
> それはPythonじゃなくてエディタの機能の話だろ。
また、インデントの深いところの複数行をまとめて (エディタからインタプリタに)
コピーするのは不可能だよね、という話?
先頭に空白が入っていると、無理。
493:デフォルトの名無しさん
08/02/01 12:11:32
矩形選択できるエディタで先頭の空白をさければいいんじゃないの?
何を無理とか不可能とか言ってるのかよくわからん。
494:デフォルトの名無しさん
08/02/01 14:25:29
>487 でほとんどの人は困ってないと思うんだよね…
495:デフォルトの名無しさん
08/02/01 14:28:31
そんな石器時代的な方法で我慢しないと駄目なのか。
496:デフォルトの名無しさん
08/02/01 16:53:18
primitive な方法で解決できるのが一番いい
497:デフォルトの名無しさん
08/02/01 16:55:02
ところで、python に else if ってないんだけどさ・・・>>488
498:デフォルトの名無しさん
08/02/01 21:29:48
使ってるエディタによりけりかもな。
なんだかLispみたいだ。
499:デフォルトの名無しさん
08/02/01 21:34:17
>>485
うわあPython読みにくう・・・。
500:デフォルトの名無しさん
08/02/01 23:35:29
なんで行単位で範囲選択できるエディターを使わないんだろう
501:デフォルトの名無しさん
08/02/02 00:53:56
だいたいがだ、インデントに関連したバグで悩まされた経験が
オマエラあるのか。俺は18年のプログラム暦で一度もない。
502:デフォルトの名無しさん
08/02/02 01:01:47
>>501
確かに。俺も 20年位インデント関連のバグ書いて悩んだことはないな。
インデントが見栄えだけしか意味持つ言語使ってないから。
503:デフォルトの名無しさん
08/02/02 01:35:12
アンインデントするときに空行が入っていないソースを
ペーストしようとするとエラーになるんですけど
どうしたらよいのでしょうか?
504:デフォルトの名無しさん
08/02/02 01:35:20
>>502
まともなエディタ使ってたら、インデント起因のバグなんてありえんよ。
むしろコーディングに余計な手間を強いるPythonはクソ。
505:デフォルトの名無しさん
08/02/02 01:41:42
>>500
>行単位で範囲選択できるエディター
ってどんなのがあるんでしょうか。
506:デフォルトの名無しさん
08/02/02 01:45:46
>>505
Vim
507:デフォルトの名無しさん
08/02/02 01:58:01
ぶっちゃけていえばだ、「インデントに起因するバグ防止のため」とか
「読みやすさのため」という理由は、全然説得力ないのよ。
「インデント起因のバグに悩まされた」ことなんてないし、「インデント
がそろってないために読みづらい」ソースなんて、小学生ならいざ知らず
普通のソースコードで見たことない。
それなのに、これまでエディタで自動で出来ていたインデントを
手動でやる羽目になる手間といったら!Python使いってなに考えてんの?
508:デフォルトの名無しさん
08/02/02 02:08:49
>>507
全くそうだよね。
インデントなんか制御構造に使わなけりゃ、
(自分にとっては) pythonほとんど完璧だたったんだか。
これは失敗だったと思うよ。インデントを制御構造に使わないとならない
積極的な理由なんかないんだから。(たぶん)
509:デフォルトの名無しさん
08/02/02 08:37:44
かっこうざい、というのは積極的な理由にならない?
(endうざい、も可)
Python で書いてると、コロンもうざい
510:デフォルトの名無しさん
08/02/02 11:08:31
ブロックの表現法にどれを採用するかなんて作者の趣味で
積極的な理由なんて無いんじゃないの?
問題が無ければ現状維持で良い。問題があるなら、
問題点と改良案を提案すれば良い。むしろ言語がより良い
方向に行くために提案すべきだ。俺的にインデントでブロックを
表現するのが好きだけど、十分に納得できる理由があるなら
他の方法に変更されても全然OK
511:デフォルトの名無しさん
08/02/02 13:45:18
>>509
うざいとかいうのは気持ちの問題。
ruby信者にはendがいいんじゃないかと言われるだけ。
慣れれてこういうもんだと思えばなくなる問題。
>>510
インデントで致命的な問題があるわけではないよ。
自分も読むだけならインデントも読みやすいと思うけど。
ただ、自分で書く場合、インデントの自動整形ができないとか、
カットアンドペーストするとき、余計な作業をしないといけないとかは、
作業が増える、これは慣れて解決する問題ではない。
個人的には、ネットでなどで見つけてきたコードサンプルなどをカットアンドペーストして
自分のマシンで動かしてみようとするときに、
他の言語ではいきなりインタラクティブシェルに放り込めば動くこともあるが、
まずはインデントを確認してからなど、めんどうだなと思うこともある。
致命的ではないけどね。作業量の問題。
512:デフォルトの名無しさん
08/02/02 14:30:08
バグが起こらない限りソースコードなんか読まねーよって言う奴には
向いてないんだろうね。
513:デフォルトの名無しさん
08/02/02 15:00:14
これからはむしろソースはXMLで、専用エディターを使って見掛けを調整するような言語が求められるのかも
これなら表現は {} だろうが字下げだろうがエディターの選択に拠るのであって言語の仕様とは分離できるし
514:デフォルトの名無しさん
08/02/02 15:04:22
lispの括弧とpythonのインデントは同じ匂いがする
やってることは完全に正反対のはずなんだが…
515:デフォルトの名無しさん
08/02/02 15:33:49
ソースコードが画像っていう言語は見たことあるけど、
ソースコードがXMLって言うのはまだ見たことないなぁ・・・
516:デフォルトの名無しさん
08/02/02 15:49:55
SQL埋め込んだりHTML埋め込んだりすると
見た目にインデントが混乱するので嫌
ちゃんとしたエディタならどっちも文字列だから
プログラム自体のインデントには影響しないんだけど
読むのがきつい
そういうときは構造が間違ってるから見直せとか
テンプレ使えって話になるんだろうけど
517:デフォルトの名無しさん
08/02/02 15:52:27
>>515
わかってるとは思うが >>513 の言ってるのは
エディタ上では普通のソースと見分けが付かない
保存したときにXMLになってるっていう話だろ
そういうのを実現してるのは強いて言えば
Excel2007 の VBA とかじゃないのか
518:デフォルトの名無しさん
08/02/02 16:39:32
構文木がべた書きされた中間コードとして、だったら、S式でもXMLでも
あまり差はなくないか? XMLのほうがむやみに冗長なだけで。
あとはプログラマがプレインテキスト信仰から離れられるか、という
ところだろうけど。
519:デフォルトの名無しさん
08/02/02 16:46:34
S式なんざ一般に受け入れられないでしょ。Lispが受け入れられていないのだから。
520:デフォルトの名無しさん
08/02/02 16:55:23
特定のツールがないと編集できない言語なんて絶対流行らないという気がする。
キーワードに非アスキー文字がある言語が絶対に流行らないのと同じように・・w
521:デフォルトの名無しさん
08/02/02 17:24:24
> 構文木がべた書きされた中間コードとして
という部分を見落とされちゃった気がしてしょぼーん
522:デフォルトの名無しさん
08/02/02 17:31:12
S 式 or Lisp という文字が入った書き込みがあった時の
ボットによる定型レスだから気にしないでオケ。
523:デフォルトの名無しさん
08/02/02 18:37:17
hoge.pyc を直接開くとソースコードが出てきて
そのまま編集&保存できるエディタってある?
524:デフォルトの名無しさん
08/02/03 02:09:00
pycからソースコードって復元できないでしょ多分
525:デフォルトの名無しさん
08/02/03 02:16:30
>>520
昔のパソコンBASICは処理系依存の中間言語でセーブしてたよ
でもけっこう流行ってたと思う
526:デフォルトの名無しさん
08/02/03 09:17:27
>>525
大抵はアスキーセーブもできたはずだが?
527:デフォルトの名無しさん
08/02/03 15:59:54
ぶっちゃけ今、プログラマの、IDE エディタと専用エディタの使用比率って
どんなもんだろうね?
528:デフォルトの名無しさん
08/02/03 16:15:34
>>527
俺、3つの職場渡り歩いたけど、IDEのエディタ使ってるやつ見たことない。
529:デフォルトの名無しさん
08/02/03 21:33:30
>>526
大抵はアスキーセーブなんてしないし
それにアスキーセーブしなおせるのは「特定のツール」がある環境だよね
530:デフォルトの名無しさん
08/02/03 21:52:30
>>529
処理系自体がIDEなんだから関係ないじゃん。
531:デフォルトの名無しさん
08/02/03 21:54:28
>>530
だから「絶対流行らない」に対する反論だろ
実際普及してたわけだし
532:デフォルトの名無しさん
08/02/03 22:08:41
それしかなかった(一般に入手可能性という意味で)からだろ
533:デフォルトの名無しさん
08/02/03 22:09:17
当時はマシン自体がIDEだったわけだし。
534:デフォルトの名無しさん
08/02/03 23:49:51
同様のもので言えば Smalltalk なんかもパソコンバンドルされてれば普及したかもね
535:デフォルトの名無しさん
08/02/04 00:07:36
>>534
あると
どるふぃん
536:デフォルトの名無しさん
08/02/04 01:12:39
そもそも Smalltalk が無ければ Mac も Win もパソコンは今の姿ではなかったわけだしね。
つか、パソコンって言葉自体が Smalltalk を OS として動作する Alto や NoteTaker の
ためのもの…って話はスルーですか、そうですか。
537:デフォルトの名無しさん
08/02/04 01:27:03
>>536
うん、スルー^^
538:デフォルトの名無しさん
08/02/04 02:34:26
BASICが載ってた頃のはマイコンだしな
539:デフォルトの名無しさん
08/02/04 03:26:17
あんたら何年前のお話をしていらっしゃるのですか?
540:デフォルトの名無しさん
08/02/04 11:07:39
話を戻して、ソースコード寄りの中間言語ってどうよ、という意見についてなのだが、
IDE のプラグインだと IDE 毎につくらにゃいかんので負担が大きいなぁとか考えて
いたのだが、テキストフィルタとして実装するのはどうだろう。
541:デフォルトの名無しさん
08/02/05 09:52:02
>>486
矩形コピペできないエディタは死んでいい
>>509
激しく同意
>>523
関係ないけど、io-languageだと逆コンパイルできるよ。
インタラクティブシェルで、メソッドを定義すると、逆コンパイル?して表示してくれる。
自分の書いたのより、良い書き方で返ってきたりしてウケル
542:デフォルトの名無しさん
08/02/05 09:56:23
>>541
Smalltalkも逆コンパイルしてくれる。
時々、最適化した結果を見せてくれるから参考になる。
543:デフォルトの名無しさん
08/02/05 09:57:45
>>541
矩形コピペできるエディタを使っていながら
その機能を知らないやつ多すぎ。
とりあえずWindows系のエディタなら
カーソルを選択位置に持っていって、
alt押しながら選択してみるといいよ。
544:デフォルトの名無しさん
08/02/05 16:20:06
「プレーンテキストのようなものは何もないのです。」
Servlet Garden ≫ Unicode and Character Sets (Translation)
URLリンク(www.t3.rim.or.jp)
くだらない文字コード問題を解決しようとしただけで、
もうすでにプレーンテキストなんてなくなっているわけだよ。
しかし、その差異はエディタが吸収した。
ごく一部の人間以外は問題なく扱えている。
そこで次の段階は、構造化テキストですよ。
>>520のような言葉は、10年前にはそうなことも言われていたね、なんてい言われるだろう
545:デフォルトの名無しさん
08/02/05 18:37:52
GUIコンポーネント単位でコードを書くVBは大流行しました
546:デフォルトの名無しさん
08/02/06 02:26:30
ていうかC#とかVS無しでの作成とか想定してない感じだし
時代の問題じゃなくて MS vs UNIX 文化圏の違いという気がする
547:デフォルトの名無しさん
08/02/06 09:41:07
そのUnix文化圏でEclipseがじわじわと勢力を広げつつある件
・vi系
・Emacs系
・Eclipse等
に3分するとして、2:7:1 ぐらい?
548:デフォルトの名無しさん
08/02/06 23:56:47
まぁしかしこんな不見識なな記事もあるな
URLリンク(www.atmarkit.co.jp)
549:デフォルトの名無しさん
08/02/09 03:59:36
for~elseで2重ループ抜けはやっぱフラグ使うこれかな。
break時にも書けるけど共通の処理をここで確実にできるからミスがおきにくいし
elseを書くことで普通の言語のendを明示できる。
2重ループを抜ける場合じゃなくても
else:
pass
と書けるし。
for i in range(5):
a = True
for j in range(3):
if j == 2:
break
else:
a = False
if a:
break
コード見るのは>>549で。
それはそうと、selfってelifの書き間違いかと思った。
>>486
>>541
WindIDE無料版使ってるけど、インデントは強制だから絶対間違わないよ。
コピペしても挿入部分については適切にインデントされる。
挿入部分下も、ページの最後まで選択してTABで全部が適切にインデントされる。
コメントは微妙に残るかもしれないが。
550:デフォルトの名無しさん
08/02/09 07:44:22
こうやるのが素直じゃないの?
a = False
for i in range(5):
for j in range(3):
if j == 2:
a = True
break
if a:
break
そういうテクニカルな else は読みにくくなるだけ。
551:デフォルトの名無しさん
08/02/09 08:15:06
内部関数にしてreturnで抜けるのがスマートかな。
552:デフォルトの名無しさん
08/02/09 09:35:34
>>550
a の定義位置が間違ってるよ。
breakの有無の判定は一つのループにつき一度しかできないから。
複数のbreakがあってもフラグのセット忘れに関係なくループを抜けれるから確実で良いと思った
けど、まあそうかもしれない。
Basicみたいな、単文ならif、複数ならifb~endifとかになるやつならbreakだけで短く書く意味があるけど。
でもループが長くなるとどーしても分からなくなっちゃうな・・・
どこまで復帰するべきかが。
しかも深くなると、何段のインデントになってるかすら分からない。
タブならタブコードを表示するエディタでいけるけどなぜか半角スペースにされちゃってるし。
そういう意味ではelse:passは書かないとやばい。
普通の言語なら最初と最後の文字があるからそれを強調してくれれば見やすいけど、
pythonの場合はカーソルのある段全体に色をつけてくれないと範囲が分かりにくいな。
553:デフォルトの名無しさん
08/02/09 10:12:37
例外使わない?
554:デフォルトの名無しさん
08/02/09 12:19:44
>>553
俺も例外使う。例外ならforループどころか関数の壁を越えてbreakできる。
555:デフォルトの名無しさん
08/02/09 12:23:23
URLリンク(entrian.com)
556:デフォルトの名無しさん
08/02/09 13:55:24
まぁさ、例外あるような言語ではgotoいらないかもしれないけど、
Cとかだと普通に使うよ?
557:デフォルトの名無しさん
08/02/09 14:28:31
いや,普通には使わないわ(ww
558:デフォルトの名無しさん
08/02/09 14:35:39
>>557
そう?ファンクショントレース埋め込むときとか、以下のように
エラーの場合、リソース開放して戻るときとか頻繁に使うなぁ。
{
A *a = NULL; B *b = NULL; C *c = NULL; int result = E_UNKNOWN;
if ((a = A_new()) == NULL) {
result = E_MEM; goto END_FUNC;
}
if ((b = B_new()) == NULL) {
...
END_FUNC:
if (a !=NULL && result != E_SUCCESS) {
A_free(a);
}
...
}
559:デフォルトの名無しさん
08/02/09 15:58:34
まぁスコープ抜けるときにデストラクタが呼ばれる言語だったり、
アスペクト指向言語だったら、こんなgotoはいらないのだけどさ。
560:デフォルトの名無しさん
08/02/09 16:00:10
>>559 つーか単にGC付きならそれでいいのでは。
561:デフォルトの名無しさん
08/02/09 16:11:47
>>560
ファンクショントレースしこむには、スコープぬけるときにデストラクタ
よばれるか、アスペクト指向じゃなければ難しいんじゃない。
アーキテクチャに依存しないように仕込むには。
2007/07/11 10:10:10:[TRACE]FuncA IN (args=...)
2007/07/11 10:10:10:[TRACE]FuncA out (result=0)
てな感じに。
562:デフォルトの名無しさん
08/02/09 16:22:19
>>561
その程度ならtry:finally:があれば十分じゃん…
563:デフォルトの名無しさん
08/02/09 16:25:54
>>562
try:finallyで仕込むのメンドイでしょ。gotoと大して変わらないし。
アスペクト指向が一番楽だけど。
564:デフォルトの名無しさん
08/02/09 16:30:13
>>563
try:finally:がgotoと変わらないって…
gotoでは関数内で例外が発生した時の振舞いがまるで違うんだけど…
565:デフォルトの名無しさん
08/02/09 16:34:17
>>564
いや議論がごっちゃになってるのだけど。ロギングに例外機構を
使用しようとするところもおかしいし、例外の振る舞いとgoto
をごっちゃにするのもおかしい。
566:デフォルトの名無しさん
08/02/09 16:37:56
>>565
> ロギングに例外機構を
> 使用しようとするところもおかしいし、
全然おかしくない。
try:finally:はtry:句から抜ける時を捕まえるという、
まさにトレースにぴったりの機構だろ。
> 例外の振る舞いとgoto
> をごっちゃにするのもおかしい。
例外が発生した時にOUTの記録を残せないトレースなんて
役に立たないと思う。
567:デフォルトの名無しさん
08/02/09 16:39:39
元の議論は、gotoが必要な時があるかどうか。
>>558が提示したケースもgoto無しで十分対応できることが示された以上、
もうその時点で議論の結着はついていると思われ。
568:デフォルトの名無しさん
08/02/09 16:40:28
coreutilsとかLinuxのカーネルとか見ると、gotoって便利だなと思わないか?
569:デフォルトの名無しさん
08/02/09 16:46:29
>>566
try finallyは例外を捕まえるための機構であって、ファンクション
トレースのための機構ではない。
デストラクタでロギングするほうがよっぽどスマート。try finally
に依存したロギングよりも。そしてアスペクト指向のほうが
デストラクタロギングよりももっとスマートだといっているのだよ。
570:デフォルトの名無しさん
08/02/09 16:46:44
>>568
CとPythonでは言語の抽象度がまるで違うんだから、
coreutilsだのLinux kernelだのは参考にならない。
Cでtry:finally:と同等な機構を仕込むのがどれだけ大変かわかるか?
571:デフォルトの名無しさん
08/02/09 16:48:29
>>569
> try finallyは例外を捕まえるための機構であって、
いいえ、全然違います。ひょっとしてtry:except:と勘違いしている?
> デストラクタでロギングするほうがよっぽどスマート。
デストラクタはオブジェクトの解放をする機構であって、
ロギングのための機構ではない。
572:デフォルトの名無しさん
08/02/09 16:50:24
言語に備わっているものは自由に使えばいいじゃん。
(俺)ルールが決まっていれば混乱することもない。
573:デフォルトの名無しさん
08/02/09 16:52:32
558はせっかくPythonが提供している仕組みを無視して
Cの原始的なやり方を押し通そうとしているように見える。
574:デフォルトの名無しさん
08/02/09 16:56:40
いや、もともとCの話だったのだけど・・・。まぁPythonのようなクソ言語使ってないけど。
575:デフォルトの名無しさん
08/02/09 16:59:35
ならpythonスレに来なきゃいいのにw
576:デフォルトの名無しさん
08/02/09 17:05:22
寂しかったんだろ。
こういう態度じゃ,友達もいないだろう。
577:デフォルトの名無しさん
08/02/09 17:07:46
このスレはオフサイドルールについて議論するためのスレであって
たまたま1がPythonしか知らなかったのだと思うわけだが。
しかしオフサイドルールの話題ですらないな。
578:デフォルトの名無しさん
08/02/09 17:20:17
>>570
>556 名前:デフォルトの名無しさん [sage]: 2008/02/09(土) 13:55:24
>まぁさ、例外あるような言語ではgotoいらないかもしれないけど、
>Cとかだと普通に使うよ?
>557 名前:デフォルトの名無しさん [sage]: 2008/02/09(土) 14:28:31
>いや,普通には使わないわ(ww
ここから始まった話題なので、
今に限ってはCのgotoの話をしている。pythonは今のトピックにおいて関係なし。
Cは例外ないから>>558がgotoなしで書けるという話も決着がついてない。
ここで例外使えばいいという指摘自体が的外れ。
まあ実際gotoは無くてもいいが、あると遥かリソース開放とかは便利。
むろんGCとか例外とかがあればそっちのが便利だが。