Pythonに見られるインデントによる制御構造の是非
at TECH
1:デフォルトの名無しさん
07/01/22 22:44:02
議論よろしく。
2:デフォルトの名無しさん
07/01/22 22:46:31
過疎スレだ?ボコボコにしてやんよ
∧_∧
( ・ω・)=つ≡つ
(っ ≡つ=つ
/ ) ババババ
( / ̄∪
3:デフォルトの名無しさん
07/01/23 00:47:09
是
4:デフォルトの名無しさん
07/01/23 02:09:24
Haskell は 2 次元文法と括弧付きの文法を簡単に切り替えられるらしいね。
5:デフォルトの名無しさん
07/01/23 02:09:44
是
6:デフォルトの名無しさん
07/01/23 07:01:34
否
7:デフォルトの名無しさん
07/01/23 18:03:50
是
8:デフォルトの名無しさん
07/01/23 20:52:04
>>4
切り替えるというか混在OKでしょ
他の言語もブレースとインデント両方サポートしてほしい。
ブレースだから、インデントだから、endがうざいから
とかが言語選択の理由になってしまうのはつまらんと思う。
9:デフォルトの名無しさん
07/01/23 20:59:39
これって単に好みの問題?
10:デフォルトの名無しさん
07/01/23 23:27:21
ぶらさがり問題が起きないって言う利点が大きい。
どっちみちインデントが揃ってないプログラムは読みにくいし。
エディタが完璧に整形してくれるのが一番なんだけど。
>他の言語もブレースとインデント両方サポート
機械的に選択可能ならエディタにでも組み込めばいいじゃないかな。
11:デフォルトの名無しさん
07/01/24 04:32:33
python はこれだから気に入ったけど
メソッド第一引数 self で(ノ∀`)アチャーだったので
GroovyかPnutsに渋々移行した。
12:デフォルトの名無しさん
07/01/24 04:45:25
>>10
言語作者がめんどくさがることは各ユーザーがやればいいというわけですね。なるほど。
13:デフォルトの名無しさん
07/01/24 04:49:26
>>11
あそこはself以外の単語入れてボケるのが面白いのに
14:デフォルトの名無しさん
07/01/24 17:57:01
>>1
インデントは「制御構造」とは言わないのでは。
制御構造と言ったら普通は順構造(並んでいる順に実行)、分岐構造、反復構造のことを指す。
Python のインデントは「ブロック」を定義するための仕組みだ。
15:デフォルトの名無しさん
07/01/27 21:58:16
好きだが、diffフレンドリーでないのが困る。
ブロックをtry-exceptで囲って、さらにブロックの中のバグを取ったりする。
その差分を後で別のブランチにマージするときに、本当に大丈夫かどうか
不安になる。
>11
僕はあそこにselfを入れてくるのがわかりやすくて好きだなぁ。
まぁ、好みの問題だけど。javaのインスタンス変数への暗黙アクセスは
元々嫌いで、毎回thisって打ってたタイプなので尚更。
16:デフォルトの名無しさん
07/01/27 22:29:49
あれは言語側でメンバ変数と仮引数の名前が同一なら
this. 打つように強制して欲しかったと思う。
もしくはコンパイル時に警告を出すとか。デフォで。
17:デフォルトの名無しさん
07/02/01 08:05:12
>>15>>16
java知らないけど、その状況って解釈不能じゃね?w
18:デフォルトの名無しさん
07/02/25 23:16:18
URLリンク(en.wikipedia.org)
思ったより数少ないね。
19:デフォルトの名無しさん
07/02/26 04:59:32
pythonもどきのBoo言語てのもある
20:デフォルトの名無しさん
07/03/01 17:11:56
俺自分でインデントするのめんどくさくてテキトーに書き散らして
:%!perltidy する人なので、pythonは使えないと思った。
21:デフォルトの名無しさん
07/03/04 21:34:51
悔い改めよ
22:デフォルトの名無しさん
07/03/04 22:09:27
アーメン
23:デフォルトの名無しさん
07/03/04 22:16:35
GNUのキモイインデントが見られないというデメリットがあります
24:デフォルトの名無しさん
07/03/05 01:09:34
ンギモヂイイ!に見えた
25:デフォルトの名無しさん
07/03/05 14:25:34
何のエロマンガだよ。
26:デフォルトの名無しさん
07/03/05 15:56:37
東北人?
27:デフォルトの名無しさん
07/03/11 06:02:44
これって普通のコンパイラコンパイラツールで出来るの?
28:デフォルトの名無しさん
07/03/12 14:39:52
これってどれ?
29:デフォルトの名無しさん
07/03/13 11:10:02
Pythonに見られるインデントによる制御構造
30:デフォルトの名無しさん
07/03/13 14:57:54
LL(1)
31:デフォルトの名無しさん
07/03/13 23:15:23
是。
32:デフォルトの名無しさん
07/07/18 06:38:05
パッと見たときにブレースの方が視認性よくね?
この良さわからんわ
33:デフォルトの名無しさん
07/07/18 07:45:36
二次元映像の認識能力は人によってばらつきがあるからな。
俺はブレースを書かなくてもブロックを表現出来るのであれば積極的に省略したい。
34:デフォルトの名無しさん
07/07/18 08:26:12
>>32
慣れの問題かもしれん
35:デフォルトの名無しさん
07/07/18 08:40:10
是
36:デフォルトの名無しさん
07/07/18 09:31:08
非
37:デフォルトの名無しさん
07/07/19 08:09:51
俺は是
エディタがインデントレベルに応じて色分けとか
サポートがあるとさらに良い。
38:デフォルトの名無しさん
07/07/19 15:08:12
>>32
> パッと見たときにブレースの方が視認性よくね?
> この良さわからんわ
箇条書きした文章だと思うんだ!!
39:デフォルトの名無しさん
07/07/19 15:27:08
> ブレースの方が視認性よくね
ブレースを使った言語で、みんな視認性を良く書いてくれてるならね
40:デフォルトの名無しさん
07/07/19 18:12:01
方向音痴に地図を描かせてはいけないのと同じだ
41:デフォルトの名無しさん
07/07/19 20:55:08
Pythonは編集中にインデントレベルを変えると、周辺のレベルが思い出せなくて困ることがある。
C言語ライクな言語だとEmacsで M-x indent-region 一発で済むだけにPythonは書きづらい言語だ。(ただし読む分にはおk
42:デフォルトの名無しさん
07/07/19 22:15:05
矩形選択して一気にインデントレベルを変更するんじゃダメなの?
43:デフォルトの名無しさん
07/07/19 22:37:26
エディタの高水準なサポートを前提にした仕様だよね。
44:デフォルトの名無しさん
07/07/19 23:57:35
>>42
Emacs使った事無いのか?
45:デフォルトの名無しさん
07/07/20 06:02:52
俺は Vim 使ってるから Emacs は使わないけど、何で?
46:デフォルトの名無しさん
07/07/20 06:21:04
ちなみに Vim の矩形選択は Ctrl-V で出来る。Emacs でどうやるかは知らないけど、
今時のエディタなら当然可能だろう。俺がインデントを削る時はまず手で打って、j. で
行数分繰り返すけどね。
47:デフォルトの名無しさん
07/07/20 06:57:29
"<"涙目。
48:デフォルトの名無しさん
07/07/20 07:00:38
皮肉が通じんのか…
49:デフォルトの名無しさん
07/07/20 13:59:36
なぜ矩形選択なのかと
50:デフォルトの名無しさん
07/07/20 14:22:18
>>41
python-modeってそんなに不便なの?!
51:デフォルトの名無しさん
07/07/20 21:34:31
>43
一応エディタ無しでも組めないことはないだろ
エディタ前提のLisp系に比べればまだマシな方じゃね?
52:デフォルトの名無しさん
07/07/20 22:15:52
Lisp は紙と鉛筆がデフォルトだよ
53:デフォルトの名無しさん
07/07/20 22:27:49
ブロックの頭にカーソルを置いてC-M-qじゃダメなの?
54:デフォルトの名無しさん
07/07/20 22:34:53
Pythonだと制御構造を変えるとそれに合わせてインデントも修正しなくちゃならん。
問題はその時にどこからどこまでどの程度インデントをずらすのか、修正してる途中で忘れちまうことがあるんだな。
C言語系だとブレースをいじるだけで済む。インデントはエディタが自動で揃えてくれるが、それは必須でもない。
55:デフォルトの名無しさん
07/07/20 22:47:47
アホ過ぎる……
56:デフォルトの名無しさん
07/07/20 22:49:31
話題がループし始めたな
57:デフォルトの名無しさん
07/07/20 23:13:11
>>54
Python 付属の IDLE なら C-] と C-[
Emacs の python-mode なら C-c > と C-c <
でブロック全体をインデント/デインデントできるんだが、
そういうエディタの支援を利用しないと云々という話?
58:デフォルトの名無しさん
07/07/21 00:59:27
>57
そういう話なんじゃね?
>51 も >53 ができるエディタが必要って話だろ。
メモ帳で組めなきゃダメなのかよ。
59:58
07/07/21 01:03:55
って…C-M-qは字下げだったかorz
普段Emacs使わないから覚えてないな…
60:デフォルトの名無しさん
07/07/21 02:36:52
>>57
制御構造を変えるということはブロックの範囲や位置を変えたりとか色々なわけで、
それはエディタの機能じゃなくて人間の脳味噌でする仕事。
Pythonだとそういうエディタの機能ではカバーできない部分が煩わしいなぁ、と。
61:デフォルトの名無しさん
07/07/21 05:25:39
>>60
具体例きぼんぬ
62:デフォルトの名無しさん
07/07/21 07:33:20
みんな普段どんだけ低機能なエディタ使ってるんだよ。
63:自分が勘違いしていることに気づいてなさそうだな…
07/07/21 09:48:42
プログラマがアルゴリズムを考えずに
エディタにアルゴリズムを決めて貰うスレはこちらですか?
64:デフォルトの名無しさん
07/07/21 18:17:49
Python知らないが、こういうことだろ?
仮に
if (foo) {
proc1;
proc2;
}
と言うロジックがあったときに、proc2を条件から外したいとする。
その場合、当然proc2の行を次の行を入れ替えて
if (foo) {
proc1;
}
proc2;
とすればいい。しかし、インデント依存言語だとproc2のインデントを変えるだけで済んでしまう。
このように一個の条件式だけなら未だいいが、ループ内の条件式をループ外に出すといった場合には
インデントレベルの把握と操作が煩わしい。
65:なんでこんな奴が来てるんだ?
07/07/21 21:59:01
>インデントレベルの把握と操作が煩わしい。
脳内妄想は日記内でおながいしまつ
66:デフォルトの名無しさん
07/07/21 22:22:21
>>64
「ループ内の""文""をループ外に出すといった場合には」
が
カット->ペースト->手作業でインデント揃え
カット->ペースト->コマンド一発で勝手にインデントが揃う
の差って言いたいんじゃないか?
67:デフォルトの名無しさん
07/07/22 00:16:41
>>64
{ } を使う言語もどうせ可読性のためにインデントしてるんだから
Pythonの方が表記や操作の無駄がなくてよい
68:デフォルトの名無しさん
07/07/22 03:52:21
>>64なんてproc2のインデントレベルがそのままだったら露骨に糞コードだろ。
69:デフォルトの名無しさん
07/07/22 09:39:23
>手作業でインデント揃え
はエディタの支援で "一発でインデントを揃える" ことが出来るのに
>コマンド一発で勝手にインデントが揃う
と何が違うのか意味が分からない
70:デフォルトの名無しさん
07/07/22 09:43:52
Phython厨が意図的に理解できない振りをしているのか、それとも本当に理解できないのか、どっちなんだろ。
71:デフォルトの名無しさん
07/07/22 11:00:29
>>69
「コマンド一発で勝手にインデントが揃う」
は
{
{
{
なんとか
}
}
}
をコマンド一発で
{
{
{
なんとか
}
}
}
にしてくれる事
72:デフォルトの名無しさん
07/07/23 11:45:34
>70
いい加減飽きたからこの辺で放置しとくけど...
カッコをどこにいれるかと考えている段階&作業に相当するのが
「どのブロックをインデントさせようか」と考えてインデントする作業
なので >71 の「コマンド一発で勝手にインデントが揃う」は
そもそも比較対象が存在しないと言うか
そういう考え方が無意味なんですけどね…
python 使ったことないひとには理解できないかもしれません
73:デフォルトの名無しさん
07/07/23 12:28:23
リファクタリングしたことないひとには理解できないかもしれません
74:デフォルトの名無しさん
07/07/23 14:14:53
>>71
例えば Emacs の場合、「コマンド一発」って具体的にどうすんの?
75:デフォルトの名無しさん
07/07/23 14:50:48
>>74
>>53
76:デフォルトの名無しさん
07/07/23 16:42:15
C なら indent-region の類いだし
python-mode なら↓とかで。
C-c > py-shift-region-right
C-c < py-shift-region-left
C-c C-r py-shift-region-right
C-c C-l py-shift-region-left
インデントの意味もこまんど一発の意味合いも違うけど
77:デフォルトの名無しさん
07/07/23 22:08:38
1:1 でマップ出来ないというのはその通りだよね。
この場合は、一部を切り出して比較しても意味が無い。
78:デフォルトの名無しさん
07/09/13 00:17:09
>>74
ブロックの終端に必ずreturnかpassを付けてから整形する
79:デフォルトの名無しさん
07/09/13 00:23:14
おお、気づかなかったよ
80:デフォルトの名無しさん
07/09/13 00:45:46
>>78
それは・・・・・・
81:デフォルトの名無しさん
07/09/13 01:03:47
それじゃあ、rubyのendのほうがマシw
82:デフォルトの名無しさん
07/10/11 11:14:00
キモイ
83:デフォルトの名無しさん
07/10/11 11:39:30
FORTRAN 最強!
1〜5桁目
行番号を書く。1カラム目にCを書くとその行はコメント行になる。
6桁目
継続行であるときはここに任意の文字(空白又は0以外)を書く
7〜72桁目
本文を書く
73〜80桁目
シーケンシャル番号を書く(行を識別するための番号、本文には影響しない)
123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-
+---+-+----------------------------------------------------------------+-------+
行番号 コード
DO 10 I = 1, 100
WRITE(6,200) I
200 FORMAT(1H ,I3)
10 CONTINUE
END
84:デフォルトの名無しさん
07/10/17 23:24:36
HASKELL !!!!!!
85:デフォルトの名無しさん
07/10/26 09:46:27
関数の最後にはreturn を書くクセをつければ
def A():
....
return
の行頭空白がなくなったとしてもどうにか復元できるけど
たとえば
for i in range(10):
if data[i]==3:
break
else:
print "NOT FOUND"
で空白がなくなったらもう復元できないよね
それが怖い
for の最後には必ず continue をつけるとか。
86:デフォルトの名無しさん
07/10/26 20:35:40
>>85
何をお仰りたいかわかりませんが
つ{}
もしくは
つ他言語
87:デフォルトの名無しさん
07/10/27 17:22:48
行頭の空白が無くなったのを復元しなくてはいけない
というシチュエーションは殆ど無いから無問題かと...
2ch に慌てて貼付けた時くらい?
88:デフォルトの名無しさん
07/10/27 22:21:36
その行頭の空白も、専ブラによっては見れるからなぁ…
89:デフォルトの名無しさん
07/11/12 07:56:43
最悪ソース見ればちゃんと残ってる
90:デフォルトの名無しさん
07/11/12 20:13:43
wxGladeが吐いたコードみてみたら
if hoge :
hage
fuga
hige
# end if
みたいになってた
91:デフォルトの名無しさん
07/11/12 20:15:10
>>83
パンチカードの時代に作られた言語だから
92:デフォルトの名無しさん
07/11/12 20:20:17
>>85
for i in range(10):
if data[i]==3:
break
# end if
else:
print "NOT FOUND"
# end for
なんかださいけど
93:デフォルトの名無しさん
07/11/13 00:58:11
そんなもんいちいちつけてコードを醜くするなら別の言語を使え、
とか言い放つPython原理主義者などはいないものか。
94:デフォルトの名無しさん
07/11/13 02:19:32
>93
ノ
endとか書くぐらいならRubyでもやってろと思う
95:デフォルトの名無しさん
07/11/13 08:41:21
Pythonって実は
for i in range(10): {
if data[i]==3:
break
}else: {
print "NOT FOUND"
}
って書いても動く?
96:デフォルトの名無しさん
07/11/13 09:12:22
残念なことに構文エラーだ
97:デフォルトの名無しさん
07/11/17 00:24:01
>>85
>>78
for i in range(10):
if data[i]==3:
break
pass
else:
print "NOT FOUND"
pass
98:デフォルトの名無しさん
07/11/18 00:11:00
インデントが文法的に意味を持たなくたって、
どうせ、一秒でも保守する気のあるコードは必ずインデントして書くわけだから、
どうせだったら、インデントを文法に利用して、不要なブレースだの、endだの
を省けたほうが、合理的だし、無駄がなくて美しい。
99:デフォルトの名無しさん
07/11/18 00:18:51
不要なselfもなくしてください
100:デフォルトの名無しさん
07/11/18 01:11:44
変な記号をつけるよりselfの方がまし
selfは不要じゃないよ
101:デフォルトの名無しさん
07/11/18 02:11:57
つうか、その話とインデントはまったく独立なわけで・・・
102:デフォルトの名無しさん
07/11/18 02:21:08
インデントあれば「:」も不要だと思うけど
あれは何でのこっているんだろう?
103:デフォルトの名無しさん
07/11/18 03:19:07
>>100
スコープで文脈ってものを既に導入しているのだから、
selfくらいは省略したときに文脈から判断したっていいんじゃね?
104:デフォルトの名無しさん
07/11/18 09:49:06
>>103
インタプリタの判断ミスによる副作用を防ぐために、ピリオドを含めてたった 5 文字の self くらい明示的に指定しても良いんじゃね?
105:デフォルトの名無しさん
07/11/18 10:11:23
コードを書き捨てるだけなら面倒だと思うかもしれないが、
selfが常にあるほうがずっと読みやすいコードになるよ。
106:デフォルトの名無しさん
07/11/18 10:14:23
メンバ関数定義の最初の仮引数として常にselfを自分で書かなければならない
ことだけは、冗長だと感じる
107:デフォルトの名無しさん
07/11/18 10:28:53
>>102
コロンは,英語の表記習慣から来てるんだと思う。
PEP8のImportsセクションあたり見てみ。項目を列記する前の行にコロンを使う。
URLリンク(www.python.org)
たとえばこんなの。
Imports should be grouped in the following order:
1. standard library imports
2. related third party imports
3. local application/library specific imports
108:デフォルトの名無しさん
07/11/18 12:30:54
インタプリタの判断ミス(笑)
ミスするのは人間だろう。ミスを防ぐためにselfが
必用だというならインデントをミスった場合の
防波堤としてブレースだって必用だ。
109:デフォルトの名無しさん
07/11/18 13:33:41
ブレースミスったときの対策も必要だ!
110:デフォルトの名無しさん
07/11/18 15:03:16
括弧の閉じ忘れ対策も必要じゃね?
111:デフォルトの名無しさん
07/11/18 15:59:30
コロンに関して言えば
あると見やすいだろってだけの話で深い理由はない。
112:デフォルトの名無しさん
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
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5376日前に更新/136 KB
担当:undef