Pythonに見られるインデントによる制御構造の是非

議論よろしく。

過疎スレだ？ボコボコにしてやんよ
　∧＿∧
　(　･ω･)＝つ≡つ
　(っ　≡つ＝つ
　/　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　( /￣∪

是

Haskell は 2 次元文法と括弧付きの文法を簡単に切り替えられるらしいね。

是

否

是

>>4
切り替えるというか混在OKでしょ

他の言語もブレースとインデント両方サポートしてほしい。
ブレースだから、インデントだから、endがうざいから
とかが言語選択の理由になってしまうのはつまらんと思う。

これって単に好みの問題？

ぶらさがり問題が起きないって言う利点が大きい。
どっちみちインデントが揃ってないプログラムは読みにくいし。
エディタが完璧に整形してくれるのが一番なんだけど。

＞他の言語もブレースとインデント両方サポート
機械的に選択可能ならエディタにでも組み込めばいいじゃないかな。

python はこれだから気に入ったけど
メソッド第一引数 self で(ﾉ∀｀)ｱﾁｬｰだったので
GroovyかPnutsに渋々移行した。

>>10
言語作者がめんどくさがることは各ユーザーがやればいいというわけですね。なるほど。

>>11
あそこはself以外の単語入れてボケるのが面白いのに

>>1
インデントは「制御構造」とは言わないのでは。
制御構造と言ったら普通は順構造（並んでいる順に実行）、分岐構造、反復構造のことを指す。

Python のインデントは「ブロック」を定義するための仕組みだ。

好きだが、diffフレンドリーでないのが困る。

ブロックをtry-exceptで囲って、さらにブロックの中のバグを取ったりする。
その差分を後で別のブランチにマージするときに、本当に大丈夫かどうか
不安になる。

>11

僕はあそこにselfを入れてくるのがわかりやすくて好きだなぁ。
まぁ、好みの問題だけど。javaのインスタンス変数への暗黙アクセスは
元々嫌いで、毎回thisって打ってたタイプなので尚更。

あれは言語側でメンバ変数と仮引数の名前が同一なら
this. 打つように強制して欲しかったと思う。
もしくはコンパイル時に警告を出すとか。デフォで。

>>15>>16
java知らないけど、その状況って解釈不能じゃね？ｗ

http://en.wikipedia.org/wiki/Off-side_rule

思ったより数少ないね。

pythonもどきのBoo言語てのもある

俺自分でインデントするのめんどくさくてテキトーに書き散らして
:%!perltidy する人なので、pythonは使えないと思った。

悔い改めよ

アーメン

GNUのキモイインデントが見られないというデメリットがあります

ンギモヂイイ！に見えた

何のエロマンガだよ。

東北人？

これって普通のコンパイラコンパイラツールで出来るの？

これってどれ？

Pythonに見られるインデントによる制御構造

LL(1)

是。

パッと見たときにブレースの方が視認性よくね？
この良さわからんわ

二次元映像の認識能力は人によってばらつきがあるからな。
俺はブレースを書かなくてもブロックを表現出来るのであれば積極的に省略したい。

>>32
慣れの問題かもしれん

是

非

俺は是
エディタがインデントレベルに応じて色分けとか
サポートがあるとさらに良い。

>>32
> パッと見たときにブレースの方が視認性よくね？
> この良さわからんわ

箇条書きした文章だと思うんだ!!

> ブレースの方が視認性よくね

ブレースを使った言語で、みんな視認性を良く書いてくれてるならね

方向音痴に地図を描かせてはいけないのと同じだ

Pythonは編集中にインデントレベルを変えると、周辺のレベルが思い出せなくて困ることがある。
C言語ライクな言語だとEmacsで M-x indent-region 一発で済むだけにPythonは書きづらい言語だ。(ただし読む分にはおｋ

矩形選択して一気にインデントレベルを変更するんじゃダメなの?

エディタの高水準なサポートを前提にした仕様だよね。

>>42
Emacs使った事無いのか?

俺は Vim 使ってるから Emacs は使わないけど、何で?

ちなみに Vim の矩形選択は Ctrl-V で出来る。Emacs でどうやるかは知らないけど、
今時のエディタなら当然可能だろう。俺がインデントを削る時はまず手で打って、j. で
行数分繰り返すけどね。

"<"涙目。

皮肉が通じんのか…

なぜ矩形選択なのかと

>>41
python-modeってそんなに不便なの?!

>43
一応エディタ無しでも組めないことはないだろ
エディタ前提のLisp系に比べればまだマシな方じゃね？

Lisp は紙と鉛筆がデフォルトだよ

ブロックの頭にカーソルを置いてC-M-qじゃダメなの?

Pythonだと制御構造を変えるとそれに合わせてインデントも修正しなくちゃならん。
問題はその時にどこからどこまでどの程度インデントをずらすのか、修正してる途中で忘れちまうことがあるんだな。

C言語系だとブレースをいじるだけで済む。インデントはエディタが自動で揃えてくれるが、それは必須でもない。

アホ過ぎる……

話題がループし始めたな

>>54
Python 付属の IDLE なら C-] と C-[
Emacs の python-mode なら C-c > と C-c <
でブロック全体をインデント/デインデントできるんだが、
そういうエディタの支援を利用しないと云々という話？

>57
そういう話なんじゃね？
>51 も >53 ができるエディタが必要って話だろ。

メモ帳で組めなきゃダメなのかよ。

って…C-M-qは字下げだったかorz
普段Emacs使わないから覚えてないな…

>>57
制御構造を変えるということはブロックの範囲や位置を変えたりとか色々なわけで、
それはエディタの機能じゃなくて人間の脳味噌でする仕事。
Pythonだとそういうエディタの機能ではカバーできない部分が煩わしいなぁ、と。

>>60
具体例きぼんぬ

みんな普段どんだけ低機能なエディタ使ってるんだよ。

プログラマがアルゴリズムを考えずに
エディタにアルゴリズムを決めて貰うスレはこちらですか?

Python知らないが、こういうことだろ?

仮に
if (foo) {
proc1;
proc2;
}
と言うロジックがあったときに、proc2を条件から外したいとする。
その場合、当然proc2の行を次の行を入れ替えて
if (foo) {
proc1;
}
proc2;
とすればいい。しかし、インデント依存言語だとproc2のインデントを変えるだけで済んでしまう。
このように一個の条件式だけなら未だいいが、ループ内の条件式をループ外に出すといった場合には
インデントレベルの把握と操作が煩わしい。

>インデントレベルの把握と操作が煩わしい。

脳内妄想は日記内でおながいしまつ

>>64
「ループ内の""文""をループ外に出すといった場合には」
が　
カット->ペースト->手作業でインデント揃え
カット->ペースト->コマンド一発で勝手にインデントが揃う
の差って言いたいんじゃないか?

>>64
{ } を使う言語もどうせ可読性のためにインデントしてるんだから
Pythonの方が表記や操作の無駄がなくてよい

>>64なんてproc2のインデントレベルがそのままだったら露骨に糞コードだろ。

>手作業でインデント揃え

はエディタの支援で "一発でインデントを揃える" ことが出来るのに

>コマンド一発で勝手にインデントが揃う

と何が違うのか意味が分からない

Phython厨が意図的に理解できない振りをしているのか、それとも本当に理解できないのか、どっちなんだろ。

>>69
「コマンド一発で勝手にインデントが揃う」
は

{
{
{
なんとか
}
}
}

をコマンド一発で

{
　{
　　{
　　　なんとか
　　}
　}
}

にしてくれる事

>70
いい加減飽きたからこの辺で放置しとくけど...

カッコをどこにいれるかと考えている段階&作業に相当するのが
「どのブロックをインデントさせようか」と考えてインデントする作業
なので >71 の「コマンド一発で勝手にインデントが揃う」は
そもそも比較対象が存在しないと言うか
そういう考え方が無意味なんですけどね…

python 使ったことないひとには理解できないかもしれません

リファクタリングしたことないひとには理解できないかもしれません

>>71
例えば Emacs の場合、「コマンド一発」って具体的にどうすんの？

>>74
>>53

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

インデントの意味もこまんど一発の意味合いも違うけど

1:1 でマップ出来ないというのはその通りだよね。
この場合は、一部を切り出して比較しても意味が無い。

>>74
ブロックの終端に必ずreturnかpassを付けてから整形する

おお、気づかなかったよ

>>78
それは・・・・・・

それじゃあ、rubyのendのほうがマシｗ

キモイ

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

HASKELL !!!!!!

関数の最後にはreturn を書くクセをつければ

def A():
　....
　return

の行頭空白がなくなったとしてもどうにか復元できるけど
たとえば

for i in range(10):
　if data[i]==3:
　　break
else:
　print "NOT FOUND"

で空白がなくなったらもう復元できないよね
それが怖い
for の最後には必ず continue をつけるとか。

>>85
何をお仰りたいかわかりませんが
つ{}
もしくは
つ他言語

行頭の空白が無くなったのを復元しなくてはいけない
というシチュエーションは殆ど無いから無問題かと...

2ch に慌てて貼付けた時くらい?

その行頭の空白も、専ブラによっては見れるからなぁ…

最悪ソース見ればちゃんと残ってる

wxGladeが吐いたコードみてみたら

if hoge :
  hage
  fuga
  hige
  # end if

みたいになってた

>>83
パンチカードの時代に作られた言語だから

>>85
for i in range(10):
 if data[i]==3:
  break
  # end if
else:
 print "NOT FOUND"
# end for

なんかださいけど

そんなもんいちいちつけてコードを醜くするなら別の言語を使え、
とか言い放つPython原理主義者などはいないものか。

>93
ノ
endとか書くぐらいならRubyでもやってろと思う

Pythonって実は
for i in range(10): {
if data[i]==3:
break
}else: {
print "NOT FOUND"
}
って書いても動く？

残念なことに構文エラーだ

>>85
>>78

for i in range(10):
　if data[i]==3:
　　break
pass
else:
　print "NOT FOUND"
pass

インデントが文法的に意味を持たなくたって、
どうせ、一秒でも保守する気のあるコードは必ずインデントして書くわけだから、
どうせだったら、インデントを文法に利用して、不要なブレースだの、endだの
を省けたほうが、合理的だし、無駄がなくて美しい。

不要なselfもなくしてください

変な記号をつけるよりselfの方がまし
selfは不要じゃないよ

つうか、その話とインデントはまったく独立なわけで・・・

インデントあれば「:」も不要だと思うけど
あれは何でのこっているんだろう？

>>100
スコープで文脈ってものを既に導入しているのだから、
selfくらいは省略したときに文脈から判断したっていいんじゃね?

>>103
インタプリタの判断ミスによる副作用を防ぐために、ピリオドを含めてたった 5 文字の self くらい明示的に指定しても良いんじゃね？

コードを書き捨てるだけなら面倒だと思うかもしれないが、
selfが常にあるほうがずっと読みやすいコードになるよ。

メンバ関数定義の最初の仮引数として常にselfを自分で書かなければならない
ことだけは、冗長だと感じる

>>102
コロンは，英語の表記習慣から来てるんだと思う。
PEP8のImportsセクションあたり見てみ。項目を列記する前の行にコロンを使う。

ttp://www.python.org/dev/peps/pep-0008/

たとえばこんなの。

Imports should be grouped in the following order:

1. standard library imports
2. related third party imports
3. local application/library specific imports

インタプリタの判断ミス（笑）

ミスするのは人間だろう。ミスを防ぐためにselfが
必用だというならインデントをミスった場合の
防波堤としてブレースだって必用だ。

ブレースミスったときの対策も必要だ！

括弧の閉じ忘れ対策も必要じゃね？

コロンに関して言えば
あると見やすいだろってだけの話で深い理由はない。

コロン無いと一行に書けないじゃん
if pred: body
みたいにさ

誰が書いても同じ書き方になるのが売りのひとつじゃなかったの?

>>113
んなもん、本当に同じになるわけねーじゃんよ

>>112
行末の「;」が省略可能なんだから
同様に1行に書く時だけ「:」つけるんで
いいんでないか？

self じゃなくて s で済ませば3文字減るな

ifとかforやめて全部　? にすればすごく減るよね。違いは文脈で判断。

一番重要なのは可読性であって、打鍵数を減らすことじゃないと思うんだが、と言ってみるテスト。

キーワードの短さだけを考えるんじゃねえよ。
可読性もいっしょに考えるんだ。

self、selfってうるさいのも可読性を落とすよ

>>114
だからってわざわざ複数の書き方を許すような文法にしなくてもいいじゃん

self、self ってあって下がるのは読み手のモチベーション。可読性の低下に関しては間接的な影響しか与えないんじゃないかな？

わざわざself省略とかなんでそんな無駄なことしなきゃいけないんだ

まあぶっちゃけselfには利点の方が多いのだが。
selfをいやがる奴に限って「めんどい」とかそういう低レベルなことしか言わないな。
そういうアホはPythonを使わなくて結構。

>>124
禿同。そういうヤツらって実は Python どころか、きちんと機能するコードを書けるかすら疑問。

ぶっちゃけとかいうくせに全然ぶっちゃけた話ししてないじゃん。
さっさと利点の方が多いというところをぶっちゃけてみろよ。
単に論破されるのが怖くて隠し玉をださないくせに、出せば勝てる
という根拠の無い自信ででかい態度を取ってるだけに見えるぞ。

>>124
むしろselfがキーワードでないのは半端に思えるんだが。

呼び出すときには
obj.method(arg)
と書けるのに
定義では
def method(self, arg):
と書かなければならないのも、汚い。selfがキーワードでないために
こう書かなければならないのだとしたら、それこそバカげている。

メンバアクセスを self.member のように書かせること自体は、
可読性のために良いと思えるんだが。

>>127
class.method(obj,arg)

>>128
常にそう書かせるのであれば一貫性はある。だが、実際にはそうではない、でしょ。
限定的に
obj.method(arg) にだけ第一引数省略の特権を与える合理的な理由があるとは
思えない。

関数がファーストクラスオブジェクトでない言語しか
知らないゆとりｶﾜｲｿｽ

>>130
それ、全然関係ないだろ
OCamlでクラスのメソッドを定義する時に、いちいち第一引数の
selfなんて書かせないぞ

Pythonがそうであるのは単に実装都合であり、要は手抜きだ

第一引数のself書かせないと。それは不便だな。

君らの脳内の解釈より、他人が見た時の可読性が重要なんだよ。

それがインスタンスメソッドなら第一引数がレシーバであるのは自明で、
定義に明示的にselfを書かせないとしても、レシーバを第一引数にして
クラスメソッドとして呼び出せるようにすることも出来る。

インスタンスメソッドにわざわざ常にselfを明示的に書かせるPythonは
センスが無い。

>>133
レシーバのselfをわざわざ書かせることも、それが実はキーワードでも
何でもなくて、sと書いてもいいことも、可読性の向上に何ら貢献しないのだが。

>>135
それは、あなたが賢いからなのでしょうね。私には少なくとも可読性の向上に貢献しています。

1) メソッドには第一引数が必要という割り切った仕様。欠点より利点が多いことは，ゆとりプログラマ以外には説明不要なほど自明なこと。
2) 暗黙に第一引数の名前が決まっていた方がみんな便利。
3) だからselfと書く。

これが分からない奴は他の言語使えばいいと思うよ。

ぶっちゃけクラスメソッドの場合の第一引数はclsだぜ。
文盲でない奴はPEP8を読もうな。日本語訳もあることだし。

>>137
「欠点より利点が多い」理由を説明してくれ。
obj.memfunc()
だけを省略可能にする合理的理由についてもな。

決まっていたほうが便利というのなら、それこそコンベンションでなく
キーワードにしろ、と。

あんたはPythonが現にそうである、という説明をしているだけだ。
それが良いものであるかどうかという説明にはなっていないぞ。

　

929 名前： デフォルトの名無しさん [sage] 投稿日： 2006/10/18(水) 23:39:44 
(´-ω-｀) 

Guidoは疲れ切っていた 
煩雑な構文、人によって違うスタイル、そして見えない変数に。 



(´-ω-｀)Zzz 

そして眠ってしまった。しかし…… 



ﾋﾗﾒｷ━━━━(ﾟ∀ﾟ)━━━━!! 

単純な構文！スタイル強制！変数はすべて明示！！ 



俺言語ﾃﾞｷﾀY⌒Y⌒Y⌒Y⌒Y⌒Y⌒(｡A｡)!!! 

switch...case欲しいだと？　(ﾟДﾟ )ﾔﾀﾞ!! 
インデント構文がSM？　(*´д｀*)ﾊｧﾊｧ 
クラスの記述が面倒？　(　´_ゝ｀)ﾌｰﾝ Javaでもやれよ 
変数を暗示で使えるようにだと？　(＾A＾)っPerl 


俺言語ヽ(´ー｀)ノﾊﾞﾝｻﾞｰｲ 

obj.memfunc() が本当に省略なのかについて

欠点:
　ゆとりが理解不可能なこと。
利点:
　それ以外全部(wwww

>obj.memfunc()
>だけを省略可能にする合理的理由についてもな。

意味不明。ゆとりなりに頭を使って，丁寧に説明してくれよ。
それが礼儀ってものだろ(wwwwww

>決まっていたほうが便利というのなら、それこそコンベンションでなく
>キーワードにしろ、と。

嫌だね。たまにはselfというローカル変数を作りたくなることもあるし(www

>あんたはPythonが現にそうである、という説明をしているだけだ。

そして，お前はまずPythonの現状をよく調べろ。
作者タソがみずからselfの存在意義について言及している文章がたくさん見つかるよ。
あ，ごめん，日本語もできないゆとりが英語なんて読めるわけないよな(wwwwwwwwwww

>>138
>決まっていたほうが便利というのなら、それこそコンベンションでなく
>キーワードにしろ、と。

キーワードは主にパーサーのためにあるのであって，ゆとり脳のためにあるのではないのだが。

説明できない人は要りません

Python信者発狂。
インスタンスメソッドのレシーバにselfだのthisだの書かせない
大半のオブジェクト指向言語よりPythonの方法のほうが「いいものだ」
と無根拠に主張して、その理由は説明できんらしいな。

>>142
あまりイジめちゃ可哀想だよ。この議論、ゴールドセイントにスティールセイントが戦いを挑むようなモンなんだから。

>>145
いやいや信者かどうかは微妙だぞ。
ここぞとばかりに荒そうとしているのかもしらん。
かなり頭悪そうだからなあw

> 嫌だね。たまにはselfというローカル変数を作りたくなることもあるし(www

Python信者は自分の都合に応じて「可読性」と言い、
時にはselfというローカル変数を作ってコードの読者を罠にはめるわけか。

で、classだのwhileだのforだのinだのというローカル変数を作りたくなることは
ないのかい？

他の予約語がもっと多い言語を使っているヤツがゴチャゴチャ言うな。

何だその煽りにもなってない煽り。

>>145
逆に大半のオブジェクト指向言語の方法のほうが「いいものだ」という、あなたの根拠を聞きたいものだね。

喧嘩すんなよ。というか、self云々はスレ違いだろ。
selfはウゼーってことで終了しようよ。

>>148
>で、classだのwhileだのforだのinだのというローカル変数を作りたくなることは
>ないのかい？

ぶっちゃけないよ(wwwwwwwwwwwwwwwwwwwwwwwwwww

>>153
selfはあるのに？

論理破綻はなはだしい。

>>148
高々20数個の予約語も覚えられず，予約語と同名の変数を作りたくなることがあるとは！！！
ゆとり脳恐るべし！！！！！！！

>>151
インスタンスメソッドの第一引数は自明なのだから、その定義において
毎回それを書かせるのは、obj.mem(obj)が冗長であるのと同じ理由で
冗長であり、可読性にも貢献しない。それで十分では？

>>155
お前は文盲か。

>>154
155が言っているとおり，予約語と分かっているキーワードを変数名として使いたくなることなんてねえよ(wwwwwwwwwwwwwwwwwwwww

>>152
全てのselfがウザいと言っているのではない。
インスタンスメソッド定義にわざわざ「常に」selfと書かせるのが
ウザいと言っている。

「常に」書くってどういう意味かわかるか？
場合わけがそもそも存在しないんだから、それは自明なんだ、自動化できるんだ。
それをわざわざ人手でやらせてるんだ。
馬鹿馬鹿しいことこの上ない。

>>158
文盲がお前とアイツと二人いるってことか

>>158
つまりselfがもともとキーワードとして設計されていれば、文句を
言わないわけだ。
自分のバカさ加減、論理矛盾に全く気づいていないようだねえ。

>>159
>インスタンスメソッド定義にわざわざ「常に」selfと書かせるのが
>ウザいと言っている。

self書かない方が逆にまぎらわしくね？(wwwww

>>162
メソッドのプリフィックスにm_つければおｋ

(w

で抽出すると、バカが浮き彫りになりますな。

>>164
164が抽出されました(wwwwwwwwwwwwwwwwwwwwwww

で、別にselfはもういいでしょ。
見る人によって利点でもあり欠点でもあるってことで。
すれ違いのことで喧嘩するとか、まともな大人とは思えませんよ。

>>165
小学生ですかあなたは。

だいたいさあ、Python全肯定しちゃう人ってなんなの？Pythonと自我が融合してんの？

しかしキーワード増やせなんてプログラマの発言とは思えんな

ようするにですね、僕がselfを持ち出したのは、>>166の結論を
selfに対してではなく、ブレースvsインデントの議論に対して
導ければと思ってなのです。ですからスレ違いではありません。

selfに欠点があるのは認めるよ。
そして星の数ほどの人間が、selfをなくす提案をしてきたんだ。
でもそのたびに、self不要論者は論破されて負け続けてきた。
そして誰も、selfなくせと言わなくなりましたとさ。

別にselfをキーワードにしなくても、省略可能にすることは可能だろうけどね。

もう俺言語を作るしかない。基本は型無しのC#。これ。

>>171 からすると、
ここでselfについて議論しているヤツらはソースが英語だからと言ってチェックを怠ったヤツらの集まりということで終了。

残念。2chはその英語のソースをチェックしない人たちの集まりなのです。

まあFAQなんだけどな。

http://www.python.org/doc/faq/general/#why-must-self-be-used-explicitly-in-method-definitions-and-calls

ゆとり脳のためにFAQを翻訳してやるけど，「よくある質問」ってやつだよ。
英語を勉強して5年後くらいに読んでみれば？(wwwwwwwwwwwwwwwwwww

虎の威を借る狐だな

頭のないゆとりよりはマシだろう

>>176
理由の1および3は、メソッド定義の第一引数のselfが好ましい理由の説明に
なってないな。
常にself.memberと書かせたほうがいい理由にしかなっていない。そしてそれは
別に否定はしない。

理由の2については、clazz.mem(obj, arg)と書けていいよ、と言っているわけだが、
別にメソッド定義でわざわざselfを手で書かせなくとも、そう呼び出せるように
設計することは可能なわけで、理由としては非常に弱いと言わざるを得ない。

ところで159は自分が場合分けしてる事に気づいてない模様

バカがひとりいると、バカを納得させるために細かいルールを作る必要がある。
バカは大抵暇だから、バカほど声が大きい。バカには仕事をさせない方が組織の能率が上がるから。
それがウザイので、他の言語に行ってくれていいよ。

>>176
次からは、生半可な自分の知識で煽って壮絶に敗北する前に、そのURLを提示するんだ。

今回の経験を生かせば、お前もようやくゆとり脱出の足がかりが出来たことになるよ。

>>180
Pythonは第一引数のselfのありなしでインスタンスメソッドかどうかを
判別しているのではない、でしょ。
つまりselfは冗長で余計。
selfをsとか書けたからといって、Python信者が好きな可読性とやらが損なわれるだけ。

>>182
問題提起する前にFAQを先に読んどけよ(wwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwww

草はやし過ぎ
>>179に自分で回答できるぐらいの頭はないのか
無いんだろうな

>>181
今ここに実例がいますしね(あなたのことではありません。念のため)

あえて言おう、ググレカス、と(wwwwwwwwwwww

>>184
知ってる？
2chで煽りに使われるwの数は、自身の悔しさ度が反映されるんだよ？

実際どんどん多くなってるでしょ？イライラしすぎでみてらんない。

>>186
そう、あなたのことです。(念のため)

自分のことを言われていると思ったのか…

こういう時のために２ｃｈ先人たちは「オマエモナー」という予約語を用意してくれているようですね。

>>190
Pythonのルールに従えないバカに言われたくないだけ

Pythonを使う際にルールに従うのは当たり前ってか、そうじゃなきゃ使えない
言語設計に疑問を持つのは別の次元の話

Python信者は頭が良すぎて感心するわ

じゃあ、宴も酣ですし、そろそろ>>170に、ここらインデントの議論に導いてもらいましょうか。

170は逃げたようです

逃げたんじゃないよ、
FAQを読んでるんだよ(wwwwwwwwwwwww

(w クンは黙っててください。息が草臭いです。

(wも予約語にすればいいんじゃね？ww

　　　　_, ._
　　（　・ω・）　んも〜
　　○=｛=｝〇,
　 　|:::::::::＼, ', ´
､､､､し ､､､((（.＠）ｗｖｗｗＷＷｗｖｗｗＷｗｗｖｗｗｗｗＷＷＷｗｗＷｗ

草刈りなんてしてないでインデントの議論に導いてくれよ＞１７０

私は170ではありませんまので、その問いは意味が不明です。

個人的にself以外の文字列をselfに使ってる人居ませんか？

myがいいね。my希望

まず、Pythonにあるのは関数で、メソッドではない。
obj.method という式は、 class.method の第一引数に obj をbindしている。
なので、
m = obj.method
m()
とするだけで delegate になる。

次に、selfを省略できないワケ。
動的言語は、オブジェクトのメンバがコンパイル時に決まらない。
変数の参照で、その変数がローカル変数なのかメンバ変数なのかが
関数の定義を見るだけで区別できないのは非常に危険なので、メンバ
変数への参照はローカル変数への参照から区別しなければならない。

Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
それはあまりPythonicでは無いだろう。

>>204
@classmethodとか書かせるし、チュートリアル等のドキュメントで
しっかり「メソッド」と書いてあるのに、
＞Pythonにあるのは関数で、メソッドではない。
というのはどういう意味で言ってるんだ？

↓こういう風に書けるってことだと思うが、
本当のところは本人に聞いてけろ。

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()

なるほど、意図は理解した。
JavaScriptでもそのように書けるが、JavaScriptでは引数のthisは書かなくていいな。

>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。

オレはこれが嫌いでRubyやる気無くした(ww。

関数っつーか，厳密に言うと「呼び出し可能オブジェクト(callable object)」だと思う。
ゆとり脳に理解不能な話題はやめてさ，そろそろインデントの議論に戻らないか？

>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。

privateなメンバはアンダーバーを二つつける、という、割とよく似た性質のルールがPythonにもありますけど。

Pythonicでは無いから、とか意味不明な理由を持ち出すのは止めといたほうが。

>>202
Python3.0になったら「俺」にする予定

>>210
そのルール知らなくても、private使わないでプログラム書くのは簡単。
そのルール知らなくても、他の言語のプログラミング経験があれば
そのルールを使ったプログラムを読むことが可能。
それがRubyやPerlの「知らなきゃ読めない」ルールとの差。

Python方式でもRuby方式でも実現できることを、Python方式で
実現しているということに、「Pythonicだから」という以上の理由が
何故必要？

>>212
あのさぁ、その「知らなきゃ読めない」とかも意味不明だってことに気づいてないでしょ。

例えば、"リストの内包表記"を知らなくて読むことが書くことが出来るか？
出来ないんだよ。

もし「それぐらい推測出来る」とかバカ言うなら、Rubyの@つけるルールだって推測できるだろ。



>Rubyはメンバ変数を区別するのに専用の記号とルールを用意したが、
>それはあまりPythonicでは無いだろう。

第一、210のレスは↑に対するレスだって理解できてる？

Rubyのようにメンバ変数を区別するのに専用の記号とルールを用意するりはPythonicじゃないとかアホ言ってる奴に
Pythonにも既に似たようなルールがあることを教えてやってんだよ。わかる？
お前のレスの意味不明さが。

次はせめて中学校卒業してからレスしてな。

インデントは・・・

インデントはとても合理的だけど、
ブレースによる制御構造も混在しててもいいんじゃないかと思う。

>>213
イタタタタ(wwwwwwwwwwwwww

関数の右とかifやwhileの右とかの「:」も知らなきゃ書けん罠

>>213
Java系言語一つでも知ってたら、 self.foo を見て、これは this.foo だと気づく。
@foo を見ても判らんだろ？

self.__foo を見て、private変数だと判らなくてもプログラム読めるだろ？
しかも、なんとなく他人が気軽に触っちゃいけない雰囲気かもしだしてるだろ？

内包表記も、他の言語で内包表記見たことあるなら一瞬で判るし、
そうでなくても後でリストとして利用している部分を見れば雰囲気で判るはずだ。

それでもって、private変数もリストの内包表記も、使わなくても普通に
プログラム書けるだろ？なら特殊ルール導入しても良いのがPythonic
なんだよ。
論点は特殊ルールの存在自体ではなくて、その特殊ルールを知らなくても
プログラムが読める＆使わなくても普通に書けるって事。

三行でおｋ

>>218
> Java系言語一つでも知ってたら
メジャーな言語との類似性から来る類推性、分かりやすさ、
習得しやすさおよび学習・移行の容易さを重視するんなら、
現状では好む・好まざるに関わらず、C系のシンタクスがベストだよ。
そういう意味ではself.fooではなくthis.fooのがずっといい。
selfをmeとか書いてもいいなんてのは論外だ。

__init__だの__call__だのが@と大して違いがあるとも思えんな。
単にPerlチックな記法が嫌いなだけじゃないのか。

既存の言語に似せていないのに無根拠に「こっちのが分かりやすいだろ」と
Pythonicという名前の宗教を押し売りするんだよねえ

既存のメジャーな言語に似ているものが多くの人にとって読みやすく
理解しやすいことは、自明なわけだが

メジャーな言語ってこうですか？わかりません＞＜

<main>
    <print>Hello, world!</print>
</main>

SGML系はプログラミング言語じゃねえし、
プログラミング言語じゃない言語で一番メジャーなのは英語だろｗ

XSLTはプログラミング言語と言って差し支えない気がする

メジャーなのに似てるかとか読みやすいとかどうでもいいが
_と@が同じとか言う奴はヤバい

なんか>>218を見て、作って欲しいプログラムの要件を説明するときに
「ここをこうやって (画面の前でぐっと握り拳を握る) ぐーっといろいろやって
(拳に力を込めてゆっくり動かす) ぱーっと結果を出すだけ (力を抜いて掌を開く)
でいいんだけど、簡単にできるよね」

とやってくれたオヤジを思い出した。
いや思いこみはわかるけど、わからんてばw

>>220
>__init__だの__call__だのが@と大して違いがあるとも思えんな。
だーかーらー、コンストラクタというものを知っている人なら __init__ を見て
それがコンストラクタだって推測しやすいだろ？ @ で何を推測しろと？

>>227
コンストラクタならクラスと同名のが多くのプログラマにとっては
分かりやすいに決まってるだろうに

__init__()と__new__()という一見似ているが違うものがあって……なんちゅうことを
何にも知らない奴が読んで「推測」できるかｗ

そもそも、Ｐｙｔｈｏｎｉｃってのが宗教だから意味ないと言うのなら、
Perl, Python, Ruby が平行して存在している意味がない。

end がイヤならPythonにすれば良いし、self. がイヤなら Ruby にすれば良いし、
どっちもイヤなら自分で新しい言語作ればいい。

>>228
そこまで細かい部分推測しなくても読めるじゃん。
__new__知らなくてもクラス書けるじゃん。

クラスもオブジェクトな言語でコンストラクタをクラス名と同じにすると、
クラス名が変わったときにコンストラクタで混乱するじゃん。

それに、他の言語のマネルールをいろんな言語から持ってきたら結局
判りにくくなる。それなら最初からC++なりJava使えば良い。
__init__とか__call__とか、言語にとって特殊な意味のある名前は__foo__の
形をしているというメタルールを一つ導入するだけで、覚えないと
いけない予約語を大幅に減らせる。

んだから、__fooだの__bar__だのの意味、あんたの言うメタルールは、
教わらなきゃわからんだろ
@と何の違いがあるんだ？

>>225
>_と@が同じとか言う奴はヤバい

激しく同意。まったく意味不明。

>>221
メジャーな言語に似せるつもりならインデントなんてやらねーよ。

#!/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

Ruby って色んな所で躓くよな
まったく初心者向けじゃない

RubyのことはRubyのスレでやっとくれ

しばらくぶりに来てみたらスレが伸びてるw

>>231
こういうやつは、マニュアルとかは読まないで全て始めるのか？
分かんないもの出てくりゃ調べればいいじゃん。
自分が最初にPythonの__やRubyの@に馴染めませんでしたって、
過去の恥を晒してるだけじゃん。

バカがいるとスレが伸びる(wwwww
バカが居なくなったからスレが沈静化した(wwwwwwwwwwwwwwwwwwwwwwww

延ばすな馬鹿

止まっちゃった・・・

本当に止まっちゃったね。

インデントについての話じゃなく、selfの是非とか話題がそれると盛り上がるところを見ると、
Pythonのインデントによる制御構造って言うほど悪くないんじゃない？どっかの専門家が
言った意見を素人がそのまま自分の意見として言っているようにしか感じないね。

慣れの問題でしかないからな
要は構造が示せればいいだけなわけだし
括弧でもインデントでもフローチャートでも

インデント使うと括弧の対応を自動でチェックしたりしてくれない
素のエディタでもさほど問題にならない、程度の事じゃないかな

実際 Python 使ってみると
インデント崩れで起こるトラブルよりも
それ以外の原因でいっぱいトラブルからなぁ

>>244
ウンウン、頭が悪いといろいろ大変だよね。

一番トラブルのはcopy忘れだな

悪くはないけど良いとも思わないってのが正直なところ
実際にはどうでもいい

インデントは全然苦にならないんだけど式と文が区別されてて
代入したものをすぐ次の用途に使うときとかに面倒なのが気になる

>>248
>代入したものをすぐ次の用途に使うときとか

そんなuglyなコードを書く人とは一緒に仕事したくありませんね。

一度代入したら十年は寝かさないとね

そうじゃなくてさ。
たとえば、代入と評価は分けて書いた方がいいよね。

おめーの次のセリフはこうだ
「ワンライナーを侮辱するなJOJO」

ワンライナーを侮辱するなJOJO！・・・ハッ！

どうも。インデントは、どうせ言われなくてもやるから、それほどは
違和感を感じてない初心者です。

でも文法的にインデントをブロックの識別に利用しているのなら、
IF 文の末尾に : (コロン) を付けなくても、次の行がインデントして
るならブロック開始なんだから : はいらない子なんじゃないの？
……という疑問が拭えません。

どうして : があるのか、どなたかすっきりさせてください。

if condition == True: break;

みたいな書き方をしたい場合はある。こういう場合はコロンがないと超不便。

でもそれは : じゃなくて ; でも同じだからな
次の行に回した時にも省略できない理由にはならないし

必要か必要でないかだけを言えば必要ない。

でもこの二元論は、
forいらねwhileだけでいいだろとか、
他の言語いらね真のプログラミング言語Lispが既にあるとか（ｗ
そういうたぐいのものに近い。

コロンが使われている理由を探すとすれば、
ABC言語の影響を受けているというのと、ある方が見やすいだろっていう辺りになる。
ttp://mail.python.org/pipermail/python-list/2000-December/063055.html

コロンが付いている理由はエディッタのオートインデントの実装が楽だからだと Guido がどっかで言ってた記憶が

if の : はなんとか納得できるんだけど
else の : はなくてもいいような気がする

あーその話で思い出したけど、
forにelse使えるなんて、最初何かの間違いかと思ったよ

>>257
>forいらねwhileだけでいいだろとか、
>他の言語いらね真のプログラミング言語Lispが既にあるとか（ｗ

小さい悩みだなw
そんな事言われて気にしてるなよ…

>>260
forとかwhileを抜けたあとで
全部の要素ループして抜けたのか
途中で中断して抜けたのか
知りたいときって結構あるんだよね
Pythonは痒いところに手が届きますな

>>262
>Pythonは痒いところに手が届きますな

細かいところまで練られている感じがするよね。
Pythonの良いところだと思う。

>>255
そういう書き方が出来なくても、Python 的には困らない気がします。

>>257
良いポインタの紹介ありがとうございます。やはり冗長だと思ってる
人はいるのですね。

それにしても、キータイプ数を減らすのではなく、冗長性を減らすの
でもなく、見易さを求めるのが Pythonic ってことなんだと受け取って
よいのでしょうか。

Python を触り始めて、面白いとは思っていますが、そのコンセプトが
まだ掴めなくて……ちょっともどかしいカンジの初心者です。

悟れ。

import this

かゆい所に手が届くくらい練られてるならswitchを作れ！
手が届く範囲だけ痒いって言ってるだけだろ自己満足だ！

switchはelseifで大抵代用可能だが
elseifはswitchで代用不可能なケースが多い

>>267
目の玉がかゆいのなら
目の玉を取り出さないと掻けないぞ(wwwwwwwww

これか
http://ja.wikipedia.org/wiki/%E9%A0%AD%E7%97%9B

:が見やすいかどうかはフォントによるな。
次はエディタのフォントも言語仕様になるのかな。

>>268
代用できるっちゃできるが、
if c == 1:
elif c == 2:
elif c == 3:
とかいうif〜elifの羅列は、switchのほうがずっと綺麗に書けるでしょ。
if〜elifだと、変数名を変えたら分岐の数だけ直さなければならなくなる。
「他で代用できるものは要らない」と言うのなら、Pythonは要らないものだらけだよ。

Pythonっていろいろ理由付けてるけど、
最終的にはGuidoの好みだからなぁ。
まともに反論してると馬鹿を見る

>>272
それをswitchで書き換えてずっと綺麗になった！と言うのはセンスを疑う

>>271
>次はエディタのフォントも言語仕様になるのかな。

なるわけないだろバカじゃね？？？(wwwwwwwwwwwwwwwwww

>>272
> 変数名を変えたら

そういう状況は、分岐の形式以前の問題になると思う

>>273
ソースが公開されているんだし、作者の意向に反してこうした方が良いと思える点があるんなら、自分で改良すればいいんじゃないかな？

>>277
それならPythonベースにする必要はないんじゃないかな？
十分ストレスがない言語が別にあればそれを使えばいいんじゃないかな？

>>274
まぁ結局センスの問題だわな

たいてい
if c == 1:
elif c >= 2 and c <= 8:
elif c == 9:
みたいな使い方することの方が多いからなぁ
rubyのswitchはそれが出来るけど

>>273
>Pythonっていろいろ理由付けてるけど、
>最終的にはGuidoの好みだからなぁ。

Guidoの理由付けに反論できるくらいなら、
Pythonを越える言語をデザインできるセンスがあるってことだと思う。

せいぜいがんばって。

それくらいは割と誰でも出来そうだな。
その後のモチベーションをキープするのが一番面倒なんだよ。

安奈お前の愛の火はまだ燃えているかい

>>280
それがswitchでできてもswitchの意味ないわな。

if c == 1:
elif c == 2:
elif c == 3:

これってかなりダサいプログラムだよ
普通は関数テーブル作ってcでdispatchだろ

エディタのマクロに「行末ｾﾐｺﾛﾝの後はｱｳﾄﾃﾞﾝﾄ」という俺ルールを仕込んでみた

じゃあpassのあとに（ｒｙ

じゃあオレは
セミコロンキーに改行+アウトデントを割り当てときますね

>>282
>それくらいは割と誰でも出来そうだな。

がんばって俺言語作れよ。
言いっぱなしは　と　て　も　恥ずかしいぞ（ｗｗｗ

>>289
恥ずかしいのはお前だよ。本当に丸出しだな。
そんなの大抵のプログラマなら一度は通る道だぜ。

というか、俺言語を作った事が無いプログラマってそんなに多いのか?

俺言語を作っても、多くの人に受け入れられるものは少ないんじゃない？それができるのならRubyやPythonの開発者のように、それで食っていけるだろうし。
まぁ、できなくてもプログラマとして食ってるヤツは嫌というほど見てきたし、そんなムキになるほどのことでもないような気がするんだけど。ボクはできない方だな (自爆)

> それで食っていけるだろうし

えっ、他の仕事もしてるんじゃないの？

ぼくちんはただいまヒキコモリちうなんですが、
ぱいそんをべんきょうしているので
いずれはGoogleにはいって、
いちねんくらいでいっしょうつかいきれないくらいのおカネをかせぐつもりでいます！！！
こんなぼくちんをおうえんしてくださいね！！！！！！

> えっ、他の仕事もしてるんじゃないの？
「それで食っていける」と「それだけで食っていける」は意味が違うと思います。

Pythonに文句あるなら俺言語作れw

>>292
この流れでは多くの人に受け入れられるかどうかは話してないだろう。
ユーザ多い＝良いとか言ってる奴はPerlあたりの真似しまくって結果Perl以下になって
売りは日本製だけ〜みたいなもん平気でつくりそうだ

あとユーザ数で語るならRubyじゃなくてPerlを出さないとお里が知れちゃうゾ懿｣?

俺言語の話になってることがアホすぎwww

>>295
この場合は、
「それで食っていける」＝「それで食えるだけの収入がある」＝「それだけで食っていける」
じゃないか？

switch文でbreak無しのcaseで制御が下に落ちていくようなのは
どうやってelseifで書くの？どうせそんな糞プログラム書くなとか
言って正当化されるのがオチだろうけど！

>>293

「それだけで食っていける」！＝「その仕事しかしていない」
じゃないかな？

>>300

if hoge == 1:
  HOGE
elif hoge == 2:
  FUGA
elif hoge == 3 OR hoge == 2:
  if shine:
    SHINE
  else:
    IKIRO
else:
ORZ

>>300

if case1:
　CASE1
if case2:
　CASE2
if case3:
　CASE3
...

ということじゃなくて？

>300
結局その記法ってバグなのか意図なのかが
分かりにくくなることが多いし
できるようにするメリットが少ないって判断じゃなかったか?

>>303
いや、いちいち break で脱出するコードにしないと次の case もそのまま
実行される仕様の糞言語があるんだ

>>300はアレだが>>302もちょっとどうかと思うのは俺だけではないはずだ

>>302
それで納得できるのかお前は

やっぱRubyだな

このタイミングでこういうコメントを入れるから、「こういう書き方もできます」というシンタックスシュガーに踊らされてばかりで
きちんとしたドキュメントも書けない上に、生産性がないのが日本のRubyユーザだと思われるんじゃないかな？

Rubyはソースがドキュントだからってことになってるからなぁ
生産性も糞もないよなぁ

趣味で作ったプログラムを
1年以上経ってからも
保守する気になる言語

ソレがPythonだっただけだ

どの言語で書いても保守する気になるけど？

俺はドMなのでRubyで小汚く書いたソースコードでも泣きながら保守するぜ！

今まで見た中でこれは酷いと思ったのがZopeなんだが・・・・

>>310
Rubyの生産性がないと言っているんじゃない。日本のRubyユーザの生産性がないと言っている。

python厨って困るとruby叩きに走るよな。
それも必ず「糞」とか「汚い」とかの言葉が入る。

>>316
自惚れるなよ

Rubyの話題はどうでもよくね？

そろそろインデントの話に戻ろうぜ

ム板でインデントのないコードを書き込む奴はDQN

それと、全角インデントにする野郎は氏んでいいよ＾＾

>>320
そういう話だっけｗ

それは、行頭の空白文字列を nbsp に変更するプログラムを
Python と Ruby と Haskell で書いて比較するというお題と
考えてよろしいかな?

↓じゃあ、まず Python から

しーん。。。

s/^[ ]*/&nbsp;/g

話しそれるけど、これって行頭だけでなく全部やっちゃってOKじゃね？

>>324
TAB は良いんだっけ?

>>326
その前にスペース4個でも8個でも1個の になるって問題点が>>324にはあるぞ

お楽しみ中のところ申し訳ないが
ソースを追試する側としては迷惑だからやめてくれ
半角空白でも画面に出ないだけでデータは残ってるから
こぴぺするだけで直るんだが
&nbsp;にされると復元操作が必要になる
復元プログラムをセットで提示してもらわにゃ

ほえ？

>>328のコピペ環境

&lt; → <
&gt; → >
&amp; → &
&nbsp; → &nbsp;　（←何故か変換されない）

かちゅーしゃ使ってると、全角インデントが一番読みやすいんだけど

>>324は[ ]*が0回以上の繰り返しだから結論としてインデント消えてないか？
あと、キャレット付いてるからgオプション意味ない

>>332
いろいろ間違ってる

>>271
3.0でバッククオートがなくなる理由は`フォントによっては見づらいから`らしい

>>334
フォント、マジだったのかwwww
確かにそこは見にくいことがあるw

>>333
うちの環境のsedで試したところ、インデント消えて一律行頭＆nbsp;になったけど？
ただし&をエスケープする必要があったけど

>>336
sed知らんがな。
結果うp。

>>332,336
すまん。酔っぱらって勘違いしてた。

self 論議乗り遅れた('A`)

Pythonじゃなくて失礼。
Delphi だと、Selfはかけるけど、with Hoge do 内くらいしか使わないんだよね。

Pythonみたいに、宣言が必要ない言語だと、Self相当は必須なんだね。
よくわかった。

とはいえ、Self必須は面倒だな。
スクリプト言語なのに字数が明らかに多くなる・・・。（perlみたいなのも勘弁だが）
わかりやすい点がいいけどさ・・・


：のつけ時は、いっつも、忘れてわからなくなる。

>>3
($#9737◇$#9737)��

$#9737;

selfやな奴は普通に s とか _ とか使えば良いと思う。
とくに、人が書き足したりするようなコードでなければ、好き勝手書けば良いと思う。

>>342
それじゃあインデントでわざわざ記法を強制するような
Pythonの思想に反するんじゃね？？なんでもいいなら
そもそもインデントだっていらなくね？

凄い論理だ

>>339
何か勘違いしてるような…。

使う使わないは兎も角、大概のOOPLにおいて
self や this みたいな「自身」を参照するものは
何らかの形で存在してる。

Pythonの場合の self 議論は
「メソッドの仮引数に self を明示的に書かなければならない」
ってところじゃないかと。

だから "書けば" それでいいじゃん



.... 終了

WindowsAPI
hoge(hWnd, xxx);
fuga(hWnd, yyy);

それはハンドル
そしてAPIは言語じゃない

WindowsAPIは、C言語レベルのAPIだからな。
ハンドル≒OOPのインスタンス＝self という解釈なら正しいが、
そうすると、Python が、C言語レ（ｒｙ

タイトル：Pythonに見られるインデントによる制御構造の是非
【糞スレランク：Ｄ】
直接的な誹謗中傷：0/349 (0.00%)
間接的な誹謗中傷：19/349 (5.44%)
卑猥な表現：2/349 (0.57%)
差別的表現：16/349 (4.58%)
無駄な改行：0/349 (0.00%)
巨大なＡＡなど：16/349 (4.58%)
同一文章の反復：1/349 (0.29%)
by 糞スレチェッカー Ver1.12 http://kabu.tm.land.to/kuso/kuso.cgi?ver=112

Ｄって微妙だな・・

巨大なＡＡなど：16/349 (4.58%) ってソースコード貼り付けが誤判定されてる気がする

タイトル：Pythonのお勉強 Part22
【糞スレランク：Ｅ】
直接的な誹謗中傷：0/488 (0.00%)
間接的な誹謗中傷：11/488 (2.25%)
卑猥な表現：8/488 (1.64%)
差別的表現：1/488 (0.20%)
無駄な改行：0/488 (0.00%)
巨大なＡＡなど：6/488 (1.23%)
同一文章の反復：2/488 (0.41%)
by 糞スレチェッカー Ver1.12 http://kabu.tm.land.to/kuso/kuso.cgi?ver=112

>>352
またひとつ糞レスをつけおって・・・

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

結局インデントでブロック指定するのは
たいして利点は無くて欠点が大きいでOK？

欠点が無くて利点が大きい

ONE WORD, FORCED INDENTATION OF THE CODE, THREAD OVER!!!!!!!!!!!!!!!!!!!

インデントはともかくとして
pythonで書くとコードが綺麗になるのが好き

言語仕様に頼らないときれいなコードを書けないおとこの人って・・・

そうだね。Perl使いはみんな綺麗なコードを書くよね。

インデント否定派の人はエディターで自動ディデントできないからって言うのが主な理由？

ディデントって何？
ポリデントみたいな物か？

インデントの逆

アウトデント?

オフデント
バックデント
モドリデント

デデンドモリ

マジレスするとアンインデントだろ

>>359
誰が書いてもある程度読みやすくなるようにできているのだよ。つまり、書き手よりも読み手を
重視しているんじゃねぇの？　（でも、インデントの階層が深くなると、書いていて分かりづらく
なってくる。それも狙いかもしれんが。）

>でも、インデントの階層が深くなると、

それは他の言語でも基本的には同じ問題で
そうなったら大抵は何か考え直すべきとされてるでそ

Pythonもいろいろ工夫してるけど
へぼが書くとやっぱり読みにくい

>>367
そんなに強制したいなら変数の命名規則も強制しろ。
そして変数の名前から型が決まるようにすればいい。

つまり「ネストの深さ」にも「暗黙の制限」が
かかっているような言語仕様なんですね。
いくらでも深くネストできるけど、やりすぎちゃダメ！という…

つシステムハンガリアン

>>362>>364>>366
http://www.python.jp/doc/release/ref/indentation.html
この説明ではdedentと言ってる

ついでに関数とかメソッドとかブロックの中の行数も制限しようぜ。
5行以内に。

「強制すんな！おれは空白を何個入れるかで自己表現してんだ！」って思うか
「これでアホのゴミネストに付き合わなくてすむぜ」って思うかで
プログラマとしての何かが問われるだろう

>>370
そんなの強制しなくても命名規則を決めればいいだけ
従わないヤツはチームから除外すれば済むし
それくらいできないヤツはどうせダメなヤツだから
むしろ除外した方がチームのため

>>376
だよな。インデントだってコーディングルールを強制すればよいだけで
従わないやつは排除すればいい。インデントを言語仕様で強制する必用
全然ねえよな。Pythonのインデントに関する理屈は屁理屈

>>377
>インデントだってコーディングルールを強制すればよいだけで

そうそう。
インデントを廃止するかわりに，ブラケットやendみたいなキーワードを導入すればいいだけの話だよね。
簡単簡単。

ブラケットやendみたいなキーワードを強制されるのは嫌だな

Ruby書いてるときに

def range(start, end)
..
って書けないのはちょっといやだな

ブラケットがキーワードなのか

>>375
どちらもアホプログラマにしか思えない

自分たちがちゃんとインデントされてるコードを書いてるかどうかという話と
言語仕様としてインデントでブロックをあらわすということは何の関係も無いわけだけど
>>377と>>378は何を言ってるんだ？完璧に意味不明

378は皮肉だろ。多分

・378を皮肉だと分からないヤツ
・「キーワード」が「ブラケット」と「end」にかかっていると思っちゃうヤツ

どっちもPythonistaとして失格。
Monty Pythonでも見ながら基本からやり直した方がいい。

>>379
Python でもかけませんがあにか

>>385
別にPythonistaとやらになりたくはないがな
静的スコープのない言語なんて願い下げ

Pythonは思いっきり静的スコープを採用した言語だが…

まぁ378は皮肉としてはどうかと思うが

そんなこといったら、>>383のもわかってる煽りだろｗ

>>383に食いつくのはプライドが許さない

>>386
これできみはしやわせになれると思うよ。

end = 1

389=391はおれげんごをつくった。
でもだれもつかわなかった。

そうですか

そうです

おめでとうございます

end があると、endだけの行が大量に発生するのが、コードが間延びしてる感じがしてダサい
pythonの方がエディタで眺めたときに、均等に情報が並んでる感じがして気持ちいい

Pythonだとここまでで、インデント終わりってのが明確にわからないのだが、
その辺、どうやってみわけるの？

>>398
次の命令のインデントでわかる。
インタラクティブモードの場合は空行を入れることでも可。

>>399
やっぱそうか・・・
エディタとかブラウザで、どこまでスクロールすればいいんだろとか不安になるもんで

why?
kwsk

要するに「ブロック終了」に相当する単語なり文字が目に見えないから不安な気がするってことじゃないか？
自分もpythonはじめたかなり最初の方はそういう感覚があったような気がする

こういうコードに遭遇すると殺意沸くよね

def ふにゃふにゃ
　　ぴっぽろ
　　ぱっぽろ

　　# 以下不要なのでコメントアウト
　　# ぷんぱか
　　# ほにゃらら
　　 (20行続く)

　　# 2008/1/5 追加しました。
　　return "こんなところにこんなものが！”
　　

それはPythonに限らないだろ

String ふにゃふにゃ() {
　　ぴっぽろ;
　　ぱっぽろ;

　　// 以下不要なのでコメントアウト
　　// ぷんぱか;
　　// ほにゃらら;
　　 (20行続く)

　　// 2008/1/5 追加しました。
　　return "こんなところにこんなものが！";
}

いや、ちがうんだけど、
なんだかとても眠いので寝る。
続きは夢の中で議論しましょう。

じゃ、そうしましょう。
おやすみなさい。

俺も夢の中で、まってます

じゃあ俺はニシキヘビを持って行くね。

なんで来なかったんだよ！

ごめん、熟睡しちゃった。ﾃﾍ

寝て起きたらやり合うのめんどくさくなった

Pythonの場合、ブロックを跨いだ場所にカット＆ペーストしたら
必ず自分でインデント調整せないかんの？
自動整形とか出来なさそう…まぁ、そういう機能ないエディタだと普段やってることだけどさ

ブロックを跨いでるなら自動整形出来るだろ

インデント調整ってめんどくさくないんだよ！

>>412
>Pythonの場合、ブロックを跨いだ場所にカット＆ペーストしたら
>必ず自分でインデント調整せないかんの？

そういう場合、ブロックを関数とかメソッドとかに出来るし
何の関係も無い
カット＆ペーストしたら大抵は何か考え直すべき
へぼが書くとやっぱり読みにくい

考え直して関数・メソッドにする時にカット＆ペーストしない？

ブロックごとペースとしたらそのブロック全体の
インデントをちょちょいと直せばいいだけ

直すインデントの量は先頭を見れば自明



何か疑問でも?

dakara sorega mendou datte hanasi dattandaro

ペーストした時点で正しいコードになってるのと
ペースト後インデント直さないと正しいコードにならないのとの違いの話だな

めんどうじゃないよ

めんどうだよ

めんどうじゃよ

めんどうでござる

めんどうだったら

めんどうなんだからねっ

カッコで照合する言語の場合は尻尾のカッコの数を間違えて
整合性がとれなくなったりコードがおかしくなったりするわけだけど
その際の確認の手間がペーストよりも後ろ側に来てるだけ

面倒もへったくれもないし議論になってねーっつーの

カッコの数を間違えたらSyntax Erorrだと思うが

Pythonもブロックのインデントレベルが違うと構文エラー
大らかなのはアセンブラぐらいかな

何言ってんの？

Python でインデントレベルが変わるのは : の次と
戻す時だけだから他言語での括弧の不整合と同じく
エラーが出るね

よく考えろよ。

お金は大事だぞ

あふぉらっく

python 書いたことある人間がうだうだ言うのはともかく
全く書いたり試したりしないで
脳内でイチャモン生成されても的外れだってことさ

ていうかエラーが出ない人為的なミスに関して話をしてたのに
なんで「エラーが出る状況ではエラーがでるから同じだなんて」
って話になってるの？

ネタスレ状態も悪くないと思う俺がいる

>435 が思っているのもネタに過ぎないしな

そりゃエラーが出ない人為的状況はインデントの有る無しと関係ないから
つまりスレタイ読めという事

だからその時のミスを防ぐ手だてとかリカバリーの方法だよ。
カッコとかendとかある言語の方がいろいろ手を打てる。
たいていは自動フォーマッタが視覚的にミスに気づかせてくれる。
インデントとブロックを両方プログラマの手にあずけちゃうと、
プログラマがミスしたときの保険が無くなる。

括弧やendの辻褄で自動フォーマッタが気づかせるレベルのエラーなら
Python でもインデントのレベルの辻褄が合わないから同様に気づくと思うが

>>440
書き出すインデントのレベルを勘違するのがミスだろ。
既に勘違いしてるのにどうやって辻褄が合わないことに気づくんだよ。

if hige:
  fuga
  fuga
  pass

んな奴にぬるい気持ちでコピペさせない、が正しい

じゃあ熱く「俺にコピペさせてくれ！オゥイェー！ベイベー！」って言われたらどうするんだよ。

コードをコピペすんなよキチガイ

じゃぁカットアンドペーストにするよ

>>446
天才

じゃ俺はコードの代わりにコンセントを使うよ

【審議中】
　　　　　　_,,..,,,,_ 　 _,,..,,,,_
　　 _,,..,,,_/ ・ω・ヽ/・ω・ ヽ,..,,,,_
　 ./　・ω_,,..,,,,_　 l　_,,..,,,,_/ω・ ヽ
　｜　　 / 　　・ヽ /・ 　　ヽ　　　 l
　 `'ｰ--l　　 　　 ll　　 　　 l---‐´
　　　　　`'ｰ---‐´`'ｰ---‐´

まずは言語仕様の問題と開発環境の問題を区別しよう。
話はそれからだ。

そんなことより449の審議がいつ終わるかのほうが問題だ

CM明けなんじゃない？

Python 勉強中のヘタレです。
私も昔の >>402 さんのように終了記号が無いのが不安です。
気が緩んでインデントを間違えてしまう
うっかり者は使うな！という言語なんでしょうか…？
前に Python でコード書いてたら、
急に好きなおにゃのこから電話が来て
電話の後インデントしきってないのを忘れて悩みました。

おにゃのこよりインデントを大事にしろ！
おしゃべりしててもインデントを忘れるな！って言語なんでしょうか。
コードを見ていると綺麗だとは思うのですが、
書くときは正しくヘビのように絡み付いて
縛り付けられる感じがして辛いです。

皆さんインデントのミスなんてしないんでしょうか？
ネタじゃなくてホントに。

>453
俺は他の言語の出身だが、他でもインデントはキッチリ書くよ。
経験上、そうでないと自分がミスリードするし
インデントをキッチリ書くことは「当たり前のことを当たり前にやってるだけ」と思ってる。

欠点としては、自動整形が効かないってことかな。
場合によってはこれだけが痛い。

私も普段からインデントはキッチリ書く、
というか書いてないと気がすまないのですが
コードを移動したり、差分をマージする時にドキドキしてしまいます。
マージとか他の言語だと、
ひとまずペーストしてインデント揃えて、ってできるんですが
Python だとペースト〜揃える間を一息でやらないと怖くて緊張します。

まずアペンドしてからちまちま直せば良いんじゃないだろうか

% cat code01.py >> code00.py
% vi code00.py

#{

#}

というインデントのヒントをコードに埋め込めばいいんだよ。
なんという逆転の発想・・・

pass でブロック終端を表すのはかったるいとおもったけど、
...(Ellipsis)なら、それほど悪くないかなと思った・・・

> pass でブロック終端を表す
そんなことしたっけ？

もしかして、空ブロックの代わりにpassって書くのと勘違いしてる？

目印としてってことじゃねーの

emacs だと pass の行の次はインデントが強制的に1つ引っ込むんだよ
他のエディタはどうなってるか知らんが

それはEmacs特有のサービス（？）だと思うぞ

マクロがあればどんなエディタでもできそうな気がする

面白い仕掛けだね、pass でインデント終了って

do - end
: - pass
文字数は変わらないね

pass って書くなら、4回バックスペース押したほうがいいと思う。

つうか、ブロック毎にいちいち pass pass 書いてる python コードなんて
誰も読む気しない

passなんて空ブロック以外で見たことないぜ

>>467
>>461

設定次第でバックスペースは1回にできそうだな

pass じゃなくて1って書けば？

>>466
そうじゃなくて、自動整形するためのtipsの話じゃなかったのか？

個人的な感想だけど、自動整形なんてほとんど使う機会がないな。
そもそも他のソースからのコピペをする機会が少ない。その必要があるときも
ブロックを指定してインデントなりデデント（IDLE なら Ctrl-[ と Ctrl-]）すれば一瞬で済むし。
ぶっちゃけ、453さんみたいに苦痛を感じる人がいるのが不思議。

経験的に言って、Python のコーディングをきちんとサポートしてくれるツールを使えば
インデントに起因する問題は何も起こらないよ。あとは慣れの問題。

ふと、インデントに過剰反応する人は考えすぎなのかなーとｵﾓﾀ。

Python のインデントって自転車みたい。
乗れないうちはバランスとか転んだら痛いとかいろいろ考えちゃうけど、それって無駄。
乗れるようになったら意識しなくても快適に乗りこなせるようになる。

いや、だから、
いきなり }<改行> を入力すれば、勝手にインデントを1段戻した位置にズレて
次の行ではそのまま書き続けられる位置にカーソルが移るような環境に生きていると、
いちいちインデントを調整しながらコードを書くことが苦痛だと。

そういうことじゃないかと思うわけだけど。

書くコードの種類にもよるとは思うけど。

ブレースだろうがインデントだろうがブロックの把握は行わなきゃいけないものだと思うんだが

} 入れるのと Backspace 押すのとじゃ手間に大差ない気がするが

勝手に動かされるのキライ

他人のソース見るときが一番不安

>>473
> 勝手にインデントを1段戻した位置にズレて 
> 次の行ではそのまま書き続けられる位置にカーソルが移るような環境

すくなくとも IDLE や Emacs の Python モードはそういう環境だよ。
if foo is True: [Enter]
で1段インデントされるし
    return [Enter]
で1段デデントされる。return, break, continue, pass 等で終わらないブロックの場合は
Backspace の入力が必要だけど、475さんの言うとおり、C 等で } の入力が必要なのと同じ。

そういえば Emacs の C モードで複数行にわたるマクロを書いてて行末の \ が
あるのとないのとで自動インデントの振舞いが変わって難儀するのを思い出した。
あとで \ をつけてそろえようと思ってても、自動インデントで思わぬ位置までカーソルが飛んでいく。
まあ善し悪しだね。万能じゃない。

インデントでブロックをあらわすと、最小コストで構造を表現できる。
記号でブロックをあらわすと、プログラマの意図の通りの構造になっているか
ダブルチェックすることができる。

記号でブロックをあらわすと、
見た目と意図が激しく乖離するものが出来上がる現実

なんで？

>480 は初心者にコード書かせた場合の話だろうな。
確かに、ブロックを正しく書く癖を付けさせるなら、こういう言語かも知れない。

インデントブロック無しで書きたいときもあるのだ。たとえば
if (hoge) break;
とか。

switch (var) {
　　case A: hoge(); break;
　　case B: huge(); break;
　　case C: huga(); break;
}
とか。

if hoge: break

ってあるよ

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]()
だな

pythonのインデント構造って、エディタからインタプリタにコードをカットアンド
ペーストするとき、すごくやりにくいよね。
前に、プレゼンのビデオでデモをやってる人がいて、
先頭にスペースが入っちゃったりして、やりにくそうだった。
また、インデントの深いところの複数行をまとめてコピーするのは不可能だよね。

先頭に、if 1:
とか入れれば、好きな深さのコード実行できる

>>> if 1:
...           print 1
...           print 2
...           print 4
...
1
2
4

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])
ということか

副作用ワロスｗ

俺だったらこうかなあ。

    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()

> また、インデントの深いところの複数行をまとめてコピーするのは不可能だよね

それはPythonじゃなくてエディタの機能の話だろ。

>> 491
> それはPythonじゃなくてエディタの機能の話だろ。

また、インデントの深いところの複数行をまとめて (エディタからインタプリタに)
コピーするのは不可能だよね、という話？
先頭に空白が入っていると、無理。

矩形選択できるエディタで先頭の空白をさければいいんじゃないの？
何を無理とか不可能とか言ってるのかよくわからん。

>487 でほとんどの人は困ってないと思うんだよね…

そんな石器時代的な方法で我慢しないと駄目なのか。

primitive な方法で解決できるのが一番いい

ところで、python に else if ってないんだけどさ・・・>>488

使ってるエディタによりけりかもな。
なんだかLispみたいだ。

>>485
うわあPython読みにくう・・・。

なんで行単位で範囲選択できるエディターを使わないんだろう

だいたいがだ、インデントに関連したバグで悩まされた経験が
オマエラあるのか。俺は18年のプログラム暦で一度もない。

>>501
確かに。俺も 20年位インデント関連のバグ書いて悩んだことはないな。
インデントが見栄えだけしか意味持つ言語使ってないから。

アンインデントするときに空行が入っていないソースを
ペーストしようとするとエラーになるんですけど
どうしたらよいのでしょうか？

>>502
まともなエディタ使ってたら、インデント起因のバグなんてありえんよ。
むしろコーディングに余計な手間を強いるPythonはクソ。

>>500
>行単位で範囲選択できるエディター
ってどんなのがあるんでしょうか。

>>505
Vim

ぶっちゃけていえばだ、「インデントに起因するバグ防止のため」とか
「読みやすさのため」という理由は、全然説得力ないのよ。

「インデント起因のバグに悩まされた」ことなんてないし、「インデント
がそろってないために読みづらい」ソースなんて、小学生ならいざ知らず
普通のソースコードで見たことない。

それなのに、これまでエディタで自動で出来ていたインデントを
手動でやる羽目になる手間といったら！Python使いってなに考えてんの？

>>507
全くそうだよね。
インデントなんか制御構造に使わなけりゃ、
（自分にとっては）　pythonほとんど完璧だたったんだか。
これは失敗だったと思うよ。インデントを制御構造に使わないとならない
積極的な理由なんかないんだから。（たぶん）

かっこうざい、というのは積極的な理由にならない？
(endうざい、も可)

Python で書いてると、コロンもうざい

ブロックの表現法にどれを採用するかなんて作者の趣味で
積極的な理由なんて無いんじゃないの？
問題が無ければ現状維持で良い。問題があるなら、
問題点と改良案を提案すれば良い。むしろ言語がより良い
方向に行くために提案すべきだ。俺的にインデントでブロックを
表現するのが好きだけど、十分に納得できる理由があるなら
他の方法に変更されても全然OK

>>509
うざいとかいうのは気持ちの問題。
ruby信者にはendがいいんじゃないかと言われるだけ。
慣れれてこういうもんだと思えばなくなる問題。

>>510
インデントで致命的な問題があるわけではないよ。
自分も読むだけならインデントも読みやすいと思うけど。
ただ、自分で書く場合、インデントの自動整形ができないとか、
カットアンドペーストするとき、余計な作業をしないといけないとかは、
作業が増える、これは慣れて解決する問題ではない。

個人的には、ネットでなどで見つけてきたコードサンプルなどをカットアンドペーストして
自分のマシンで動かしてみようとするときに、
他の言語ではいきなりインタラクティブシェルに放り込めば動くこともあるが、
まずはインデントを確認してからなど、めんどうだなと思うこともある。
致命的ではないけどね。作業量の問題。

バグが起こらない限りソースコードなんか読まねーよって言う奴には
向いてないんだろうね。

これからはむしろソースはXMLで、専用エディターを使って見掛けを調整するような言語が求められるのかも
これなら表現は {} だろうが字下げだろうがエディターの選択に拠るのであって言語の仕様とは分離できるし

lispの括弧とpythonのインデントは同じ匂いがする
やってることは完全に正反対のはずなんだが…

ソースコードが画像っていう言語は見たことあるけど、
ソースコードがXMLって言うのはまだ見たことないなぁ・・・

SQL埋め込んだりHTML埋め込んだりすると
見た目にインデントが混乱するので嫌
ちゃんとしたエディタならどっちも文字列だから
プログラム自体のインデントには影響しないんだけど
読むのがきつい

そういうときは構造が間違ってるから見直せとか
テンプレ使えって話になるんだろうけど

>>515
わかってるとは思うが >>513 の言ってるのは
エディタ上では普通のソースと見分けが付かない
保存したときにXMLになってるっていう話だろ
そういうのを実現してるのは強いて言えば
 Excel2007 の VBA とかじゃないのか

構文木がべた書きされた中間コードとして、だったら、S式でもXMLでも
あまり差はなくないか？　XMLのほうがむやみに冗長なだけで。

あとはプログラマがプレインテキスト信仰から離れられるか、という
ところだろうけど。

S式なんざ一般に受け入れられないでしょ。Lispが受け入れられていないのだから。

特定のツールがないと編集できない言語なんて絶対流行らないという気がする。
キーワードに非アスキー文字がある言語が絶対に流行らないのと同じように・・ｗ

> 構文木がべた書きされた中間コードとして

という部分を見落とされちゃった気がしてしょぼーん

S 式 or Lisp という文字が入った書き込みがあった時の
ボットによる定型レスだから気にしないでオケ。

hoge.pyc を直接開くとソースコードが出てきて
そのまま編集＆保存できるエディタってある？

pycからソースコードって復元できないでしょ多分

>>520
昔のパソコンBASICは処理系依存の中間言語でセーブしてたよ
でもけっこう流行ってたと思う

>>525
大抵はアスキーセーブもできたはずだが？

ぶっちゃけ今、プログラマの、IDE エディタと専用エディタの使用比率って
どんなもんだろうね？

>>527
俺、3つの職場渡り歩いたけど、IDEのエディタ使ってるやつ見たことない。

>>526
大抵はアスキーセーブなんてしないし
それにアスキーセーブしなおせるのは「特定のツール」がある環境だよね

>>529
処理系自体がIDEなんだから関係ないじゃん。

>>530
だから「絶対流行らない」に対する反論だろ
実際普及してたわけだし

それしかなかった(一般に入手可能性という意味で)からだろ

当時はマシン自体がIDEだったわけだし。

同様のもので言えば Smalltalk なんかもパソコンバンドルされてれば普及したかもね

>>534
あると
どるふぃん

そもそも Smalltalk が無ければ Mac も Win もパソコンは今の姿ではなかったわけだしね。
つか、パソコンって言葉自体が Smalltalk を OS として動作する Alto や NoteTaker の
ためのもの…って話はスルーですか、そうですか。

>>536
うん、スルー＾＾

BASICが載ってた頃のはマイコンだしな

あんたら何年前のお話をしていらっしゃるのですか？

話を戻して、ソースコード寄りの中間言語ってどうよ、という意見についてなのだが、
IDE のプラグインだと IDE 毎につくらにゃいかんので負担が大きいなぁとか考えて
いたのだが、テキストフィルタとして実装するのはどうだろう。

>>486
矩形ｺﾋﾟﾍﾟできないエディタは死んでいい

>>509
激しく同意

>>523
関係ないけど、io-languageだと逆コンパイルできるよ。
インタラクティブシェルで、メソッドを定義すると、逆コンパイル？して表示してくれる。
自分の書いたのより、良い書き方で返ってきたりしてウケル

>>541
Smalltalkも逆コンパイルしてくれる。
時々、最適化した結果を見せてくれるから参考になる。

>>541
矩形コピペできるエディタを使っていながら
その機能を知らないやつ多すぎ。

とりあえずWindows系のエディタなら
カーソルを選択位置に持っていって、
alt押しながら選択してみるといいよ。

「プレーンテキストのようなものは何もないのです。」

Servlet Garden ≫ Unicode and Character Sets (Translation)
http://www.t3.rim.or.jp/~yoko-k-h/java/servlet/2008/01/31/unicode-and-character-sets-translation.html

くだらない文字コード問題を解決しようとしただけで、
もうすでにプレーンテキストなんてなくなっているわけだよ。
しかし、その差異はエディタが吸収した。
ごく一部の人間以外は問題なく扱えている。

そこで次の段階は、構造化テキストですよ。
>>520のような言葉は、10年前にはそうなことも言われていたね、なんてい言われるだろう

GUIコンポーネント単位でコードを書くVBは大流行しました

ていうかC#とかVS無しでの作成とか想定してない感じだし
時代の問題じゃなくて MS vs UNIX 文化圏の違いという気がする

そのUnix文化圏でEclipseがじわじわと勢力を広げつつある件
・vi系
・Emacs系
・Eclipse等
に3分するとして、2:7:1 ぐらい？

まぁしかしこんな不見識なな記事もあるな

http://www.atmarkit.co.jp/fwcr/rensai/freeauthoring06/freeauthoring06_1.html

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で全部が適切にインデントされる。
コメントは微妙に残るかもしれないが。

こうやるのが素直じゃないの？

a = False
for i in range(5):
　　for j in range(3):
　　　　if j == 2:
　　　　　　a = True
　　　　　　break
　　if a:
　　　　break

そういうテクニカルな else は読みにくくなるだけ。

内部関数にしてreturnで抜けるのがスマートかな。

>>550
a の定義位置が間違ってるよ。
breakの有無の判定は一つのループにつき一度しかできないから。

複数のbreakがあってもフラグのセット忘れに関係なくループを抜けれるから確実で良いと思った
けど、まあそうかもしれない。

Basicみたいな、単文ならif、複数ならifb〜endifとかになるやつならbreakだけで短く書く意味があるけど。
でもループが長くなるとどーしても分からなくなっちゃうな・・・
どこまで復帰するべきかが。
しかも深くなると、何段のインデントになってるかすら分からない。
タブならタブコードを表示するエディタでいけるけどなぜか半角スペースにされちゃってるし。
そういう意味ではelse:passは書かないとやばい。

普通の言語なら最初と最後の文字があるからそれを強調してくれれば見やすいけど、
pythonの場合はカーソルのある段全体に色をつけてくれないと範囲が分かりにくいな。

例外使わない？

>>553
俺も例外使う。例外ならforループどころか関数の壁を越えてbreakできる。

ttp://entrian.com/goto/

まぁさ、例外あるような言語ではgotoいらないかもしれないけど、
Cとかだと普通に使うよ？

いや，普通には使わないわ(ww

>>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);
　　}
　　...
}

まぁスコープ抜けるときにデストラクタが呼ばれる言語だったり、
アスペクト指向言語だったら、こんなgotoはいらないのだけどさ。

>>559 つーか単にGC付きならそれでいいのでは。

>>560
ファンクショントレースしこむには、スコープぬけるときにデストラクタ
よばれるか、アスペクト指向じゃなければ難しいんじゃない。
アーキテクチャに依存しないように仕込むには。

2007/07/11 10:10:10：[TRACE]FuncA IN (args=...)
2007/07/11 10:10:10：[TRACE]FuncA out (result=0)

てな感じに。

>>561
その程度ならtry:finally:があれば十分じゃん…

>>562
try:finallyで仕込むのメンドイでしょ。gotoと大して変わらないし。
アスペクト指向が一番楽だけど。

>>563
try:finally:がgotoと変わらないって…
gotoでは関数内で例外が発生した時の振舞いがまるで違うんだけど…

>>564
いや議論がごっちゃになってるのだけど。ロギングに例外機構を
使用しようとするところもおかしいし、例外の振る舞いとgoto
をごっちゃにするのもおかしい。

>>565
> ロギングに例外機構を
> 使用しようとするところもおかしいし、

全然おかしくない。
try:finally:はtry:句から抜ける時を捕まえるという、
まさにトレースにぴったりの機構だろ。

> 例外の振る舞いとgoto
> をごっちゃにするのもおかしい。

例外が発生した時にOUTの記録を残せないトレースなんて
役に立たないと思う。

元の議論は、gotoが必要な時があるかどうか。
>>558が提示したケースもgoto無しで十分対応できることが示された以上、
もうその時点で議論の結着はついていると思われ。

coreutilsとかLinuxのカーネルとか見ると、gotoって便利だなと思わないか？

>>566
try finallyは例外を捕まえるための機構であって、ファンクション
トレースのための機構ではない。

デストラクタでロギングするほうがよっぽどスマート。try finally
に依存したロギングよりも。そしてアスペクト指向のほうが
デストラクタロギングよりももっとスマートだといっているのだよ。

>>568
CとPythonでは言語の抽象度がまるで違うんだから、
coreutilsだのLinux kernelだのは参考にならない。

Cでtry:finally:と同等な機構を仕込むのがどれだけ大変かわかるか？

>>569
> try finallyは例外を捕まえるための機構であって、

いいえ、全然違います。ひょっとしてtry:except:と勘違いしている？

> デストラクタでロギングするほうがよっぽどスマート。

デストラクタはオブジェクトの解放をする機構であって、
ロギングのための機構ではない。

言語に備わっているものは自由に使えばいいじゃん。
(俺)ルールが決まっていれば混乱することもない。

558はせっかくPythonが提供している仕組みを無視して
Cの原始的なやり方を押し通そうとしているように見える。

いや、もともとCの話だったのだけど・・・。まぁPythonのようなクソ言語使ってないけど。

ならpythonスレに来なきゃいいのにw

寂しかったんだろ。
こういう態度じゃ，友達もいないだろう。

このスレはオフサイドルールについて議論するためのスレであって
たまたま1がPythonしか知らなかったのだと思うわけだが。

しかしオフサイドルールの話題ですらないな。

>>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とか例外とかがあればそっちのが便利だが。

どこか適切なスレを教えてやってくれ誰か

>>578
とりあえず
http://pc11.2ch.net/test/read.cgi/tech/1123726695/
にいけ。

書いておいた
http://pc11.2ch.net/test/read.cgi/tech/1123726695/199

まあ結論としてはPythonにもgotoがあってもいいねと。
使いたくなければ使わなければいいんだし

gotoイラネ

だからPythonのスレじゃねーし

selfもなくして欲しい。

いまPLSQLの仕事をしているんだけど、
インデントして見やすいように書くと、
文の終わりが深いインデントで唐突に終わってるんだよね。
Pythonってこんな感じのコードになるのかなーと思った、
Pythonを知らないやつのたわごとでした。

>>586
つ[null;]

インデントをスペース1に変更しる

インデントとブレース両方入れるのってそんなにマイナス面が多いことなんだろうか？
ジードのブレース拒否の態度とMatz のインデント拒否の態度は両方とも
合理的な根拠が感じられない。

> ジードのブレース拒否の態度

ソースきぼんぬ

以下のような特殊なエラーがわざわざ入っている。

>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance


python3000の議論が始まったときに、ブレースが入らないことだけは
最初っから完全に決まっていた。そもそもまともに議論・検討しようという態度がない。


PEP3099で、ブレースが入らない理由のところで
何も書かれておらず、「そんなことは明らかだ」
という言い方しかしていない。（議論する気がない

ブロックの記述にインデントを用いることがPythonのレーゾンデートルの一つなんじゃね？
いいとか悪いとかじゃない、それを変えてしまったらもはやPythonではない、と。

ぶっちゃけ俺もそう思う。

ブレースの利点（といわれるもの）は視認性と自動整形だけかね？

今さらブレース入れろと言われても面倒だし
どっちでもいいという仕様になるのも生理的に嫌

ブレースで視認性が上がるとは到底思えないのだが

>595
んだんだ

>>595
パーサー実装するのが面倒。
ブレースつけてもどうせみんなインデントするからいいじゃん。

ttp://www.rubyist.net/~matz/20080220.html
最後に、「Haskellみたいなブレースの使い方を採用する気ない？」と尋ねたら、
「いろんな文法の変更を試している人がいるから、その中のひとつとして考えてみる」
ということであった。これが実現したら大喜びする人も多いように思うけど
(lambdaで複文が使えるようになるし)、それほど乗り気であるようにも見えなかったので
過大な期待は禁物である。

>>598
> 「いろんな文法の変更を試している人がいるから、その中のひとつとして考えてみる」という ことであった。

日本語訳：
ウザい東洋人、あっちいけヨ。

lambdaで複文使えるようになってうれしがるやつなんて変態だけだろ。
いくつもの分がブレスに所狭しと押し込められたソースなんて汚いだけだよ。
複数の文を書くような場面では、関数定義してオブジェクトにして引き回せばいい。

Matzはなんで、Guidoが「lambdaで複文が使えるように」していないのはわざと
だという事に気づかないんだろうか
Matzは「大喜びする人も多い」ならRubyをそういう風に改造するんだろうけど
Guidoは最初から制約を利用しようとして言語デザインしてるんだから
自分とは考えが違うと理解しないかな

>>598
> 「いろんな文法の変更を試している人がいるから、その中のひとつとして考えてみる」という ことであった。

日本語訳：
愚問に答えるのは苦労するぜ

>終始フレンドリーであったことを報告しておきたい。並んで写真も撮ったしね。

Guidoはおとな

>>598
> 「いろんな文法の変更を試している人がいるから、その中のひとつとして考えてみる」という ことであった。

日本語訳：
その質問、あなたで百万回目ですから。

GuidoとRubyの間には、同じ言語の創始者としての共感のようなものがあるんだろうな。
俺たちみたいに、匿名掲示板で溜飲を下げている一般ピープルには想像もつかないのだけれど。

matzから見たGuidoとの関係： 同じ言語の創始者としての共感がある
Guidoから見たmatzとの関係： この手のイベントで握手を求めてくる百万人の1人

>>605
GuidoとMatzの間違いじゃね？

＞＞６０６
禿

Guido が松本のせいで日本人を嫌いになりませんように…

＞Guidoから見たmatzとの関係： この手のイベントで握手を求めてくる百万人の1人
ジード、自分からRuby1.9について質問しまくってたようだから、そういうわけでもないでしょ

にしても、Matz - Guidoの間でこのスレとおんなじ話題が上ってたって言うのは面白いｗ

グ・・・Guido

>>610
君にいい言葉を教えてあげよう。
「社交辞令」

>>609
guidoってオランダ人だろ？
なら元から（ｒｙ

ttp://www.youtube.com/watch?v=oEkJvvGEtB4

これ？

>>612
ヨーロッパ人はそういう社交辞令的な質問が得意だよね。

>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance

Matz「こんな機能どう！凄いよ！」
Guido「そういうのを試してる人もいるよ」(それは10年前に通り過ぎた場所だよ)

Rubyの人って独善的でいや。

リーダーに独善的でないやつなんていない

独善的であることを自覚している人と、
無自覚なまま他者を攻撃し続ける人がいるよね。

いいかげんスレ違い

>>620 は無自覚なまま他者を攻撃し続ける人

>>622はスレ違いに無自覚なまま他者を攻撃し続ける人

寛容な終身独裁者だったっけ

まあ lambda で複文云々はさておくとしても
「なんでも機能をとりいれる」ではなく
「ほどよいバランスで適切な要素だけを適切に配置」
っていうのが一番重要なんだよね…

perl のワケワカメで不要な暗黙機能満載を体験すれば
誰でも気づきそうなものだが

その辺に関しては Python の開発陣は大丈夫そうだな

まあ lambda で複文云々を言うのならProcの仕様なんとかしろと…

スレ違い止めれ

RubyはごちゃごちゃしててPerlとあんまり変わらん

そのうちPerlでRubyのコードが動きそうだしな

Perl よりは Ruby の方が俺はずっと読みやすいけどな…
どうも Perl とっつきにくい。

Perlよりマシかもしれないがそんなに大差ない
二者で比較するのでなく他の多くの言語を考慮すれば
Rubyも読みにくい方に分類される

ここは off-side rule について議論するスレですよ？
ttp://foldoc.org/?off-side+rule

> Rubyも読みにくい方に分類される
釣りにもなってない

事実を書いているんだ
ミクとは違うのだよミクとは

オレもRubyは読みにくいと思う。
スクリプトの中ではPHPが一番読みやすい。

それだとなでしこ最高？

ECMAScript 4 が最強

>>638
でもまともに使える実行環境が無いよね

ActiveECMAScriptやIronECMAScriptなんてのを期待

ECMAScript って、generatorの中に、文字列書いてたり、
var がいるのかいらないのかわからんかったり、()の省略ができるときと
できない時が混ざってて気持ち悪かったり、足し算で意味わからないcoerceがおこったり
するウンコ的な言語のこと？

>>636
　　　　　　　　　　　　　　 .| 　 |　　|　|　　 |　 　 |　　| ｜ 　 |　　 | 　 |｜　|　|
　　　　　　　　　　　　　　 .| 　 |　　|　ﾚ　　|　 　 |　　| ｜ 　 |　　J 　 |｜　|　|
　　 　∩＿＿＿∩　　　　| 　 |　　| 　 　 J　 　 |　　| ｜　　し　　 　 |｜　|　|
　　　 | ノ＼　　 ,＿ ヽ　　.| 　 ﾚ　｜　　　　　　｜　 ﾚ｜　　　　　　　|｜ Ｊ　|
　　　/　　●゛　　● | 　 .J 　　 　 し 　 　 　 　 | 　 　 |　　　　　　　｜|　　 J
　　 |　∪　　( _●_)　ミ　　　　　　　　　　　　　.｜　 　 し 　 　 　 　 J｜
　　彡､　　　|∪|　　 |　　　　　　　　　　　　　　.Ｊ　　　 　 　 　 　 　 　 ﾚ
　/　　　　 ∩ノ ⊃　 ヽ
　(　 ＼　／ ＿ノ　|　 |
　 ＼　 "　 ／　　｜　|
　　　＼ ／￣￣￣ ／
　　　　　￣￣￣￣

ここは off-side rule について議論するスレですよ？
ttp://foldoc.org/?off-side+rule

ECMAScriptはLLスレか？

def hoge(a):
  a.sort(lambda x,y: x - y)
return a
このhoge自体をlambdaで定義しようとして
hage = lambda a: a.sort(lambda x,y: x - y)
としてもsort後のaの値は返せないんですよね
hage = lambda a: a.sort(lambda x,y: x - y), return a
みたいに複文にすると怒られるし・・・

誤爆？

>>644
sortとsortedの違いは判る？

>>646
解決しました。
ありがとうございました。
hage = lambda a: sorted(a, lambda x,y: x - y)

>>644
入門書嫁。

age

水干

for i in xrange(3):
  p i
for i in xrange(4):
 p i
それぞれスペースの数が違ってても大丈夫なんですか?

p "それぞれブロックが閉じているので大丈夫です"

age

sage

python3の資料見たら相変わらずindent問題が直ってないのな。
後方互換性がなくなると聞いてワクワクしながら見てみたらがっかりだった。

インデントに問題なんてあったっけ？

>>656
インデントレベルのヒューマンエラーでブロックが変わる
結果作業量増加要因になってる。
（この式は本当はどのブロックに束縛されたいのか？等々・・）
{}でも()でもいいんだけどブロックは明示してくれないと困る。
python3ではちゃんと直すものだと思ってただけにがっかり。

そもそもインデントでブロックを明示する言語なんだからそんなの導入するわけないじゃん

エディタの機能でどうにでもなるしな
emacsだと指定範囲のインデントを1段下げるとか上げるとかいうキーバインドがあって
これで俺は不便を感じたことはない

レベルが低い。5点。
次どうぞ。

>>658
emacsでインデントの調整はできるけど、逆に言えば調整だけの支援機能なんだよね。
人のコードもさることながら、自分のコードでもこれってどっちに束縛なのかと悩まざるを得ないことがある。
mergeする時などは最悪だねえ。

まあ手間のかかる体系だよ。

どっかからコピーしてきたらすぐにインデントの段数を合わせればいいだけじゃないの？

2tab 4tab混在ソースとかなんの罰ゲームかと思う時があるねw

エディタの置換機能も満足に使いこなせない奴は何使っても苦労するだろ？

置換機能で解決する問題じゃないだろ

普通に解決するし(w

スーパータイヤ人に直してもらえ

while
　if
　　処理
　//if
//while

こんな表記すればいいんじゃね？

なるほど
ありがとうございました

ほ　ん　と　う　に　ありがとうございました

670

>>1
否、というか全く、くだらん。
私はProlog。インデントなどすることはない。

>>657
そういうあなたには、こんなソース

void func(void) {
　　if (expr1) {
　　　　....
　　　　if (expr2) {
　　　　　　...
　　　　}} else {
　　　　　　printf("バーカ\n");
　　}
}

>>672
問題はそういうソースは、エディタやlintみたいなのでインデントを自動的に修正できる。
だが、Pythonはできない（意味がかわってしまうから）

冗長なほうが優れているというのならXML風だよな

>>673
開発環境が自動的に修正する機能を持っていたとしても、
そんな機能「ウザ」と言ってOFFにしちゃう奴が大多数。

そうなん？オートインデントとか使わないのかな・・・（冗談だよ）

スニペットの自動補完みたいなのとか慣れると便利だよ
if 書いてENTERで endおぎなったり、{ ENTER で } 書いてくれたりする奴
多分、emacsとかvimとかは昔からあるんだろうけどさ

indentが壊れるのを気にする暇があったら、svnかgitに突っ込んどけ。

オートインデントは俺マジで切ってるけど
というか勝手にソースに手をつけるようなエディタ機能は全般的に嫌い

それだと、今のIDEとか切れそうになるぞｗ

インデント付けないと読み難い制御構造ということ自体、
問題というか「恥ずかしい」ことなのではないかな。

あーよくいるよな大学とかに。
まったくインデントしないでCやJavaを書く人。

俺はcatでCを書くが何か？

echoで書くよりマシ。

>>683
今どきのシェルだと、catよりecho（つーか、"")のほうが多機能だぞ。

コード投稿しようとしたらサイズ制限に引っかかって泣く泣く先頭のスペース消しました

C以来、プログラムは自由構文が当たり前だと思っていたが、
まさかFORTRANみたいなインデントを強制される言語が使われるようになるとは思わなかった。
Pythonに慣れると変な癖が付きそうなので触る気はない。OOPやるならRubyで十分。

Haskell、Clean、F#（の#lightモード）あたりもインデントでブロックを
表現するんだけどね（オフサイドルールって奴）

ぶっちゃけPythonのインデント如きにガタガタ言ってる人は認識が古いんで
改めたほうがいいよ

COBOLでもやっとけ

関数型のかの字も知らずに出てくるのはFORTRANやCOBOLか
老害って哀れだね

numpy/scipyでblasには大変世話になってるので、
Fortranを馬鹿にすんな

FORTRANやCOBOLの桁強制とPythonやHaskellのインデントはちと性質が違うと思うなぁ

インデントは強制されてもいいけど、尻切れトンボみたいにインデントがついた形のまま終わるのがとにかく嫌いだ。
コメントで}とかendとか書いておけばいいことだけど、どうせ強制するならインデントの終わりも
きちんと書かないといけないように強制するなら許せる。
とにかくソースが美しくないから使いたくないし見たくない。

>>692 あー俺逆。馬鹿みたいにendendendendendendendendって書くのだめ。
Lispで超カッコ作った人の気持ちが半分だけわかるというか。
まあendないとパンツ履いてないような心もとなさがあるのもわかるけどね。

オフサイドルールは、数学の記法から ISWIM で取り入れられたもので、
>>691 の言う通り COBOL や Fortran とは別物。
てかひさしぶりにこのスレが伸びたのを見た気がする。

>>687
それの中で一番メジャーなのPythonなのに、Pythonごときでっていいかたわないかとｗ

YAMLはオフサイドルールでブロックを表現するんだが
endマンセーでオフサイドルールに我慢できないという
RubyユーザはYAMLを使わないのだろうか

>>695
Python「のインデント」如き
とPython「如き」では日本語として意味が違うよ

RubyだとYAMLにするよりも直接書いてしまうほうが多いような気もする。

それはRubyのリテラル表記で書くってこと？
ヤメテクレー

読む分には是、書く場合は非

YAML は一見すると簡単そうなのに構文規則が複雑すぎる。
一刻も早く滅んでほしい。

生きのこるのはJSONか？

JRubyです

>692-693
俺はC系から入ってLispに行ってからPython、Rubyと覚えたからどっちの気持ちも解るｗ
C→Lispの時は驚いたよ。「括弧は最後の行に纏めるのが良いスタイル」なんだもん。
だが慣れてしまうとRubyのendendendendに辟易。
…でも結局、そのendendendendにも慣れ始めている俺が居る。

>>696
つ、つられてやるぞ！
元々XMLはRubyにもまして、end臭くて、冗長すぎるからああなったという経緯がある

>>701
そうか？HashとArrayしかないと考えたら全然難しくないよ

妙なエスケープが多いってことじゃね？

スルー推奨

>>704
692だけど、確かに今のLISPのソースはカッコを最後にまとめてるね。
大昔LISPを勉強したとき、これでえらく苦労したのを覚えてる。
当時はソースを紙に打ち出して赤ペンでカッコの対応をチェックしてた時代で、
目視でカッコの対応をチェックするのはとても大変だった。
今はエディタでカッコ対応チェックしてくれるから楽だけどね。
PythonをRubyの親戚と見ると違和感あるけど、LISPに似てると思って見ればアレルギーも少しはおさまるのかな。
でも、Cで関数の最後に}が並んでたらやっぱり嫌だな。

Lispのコードを読むときはカッコなんて見ない（特に閉じカッコは）
インデントだけ見る
EmacsなしでLispのコードを書く気はしない
かな

そういう意味ではオフサイドルールはそれなりに合理的だ
見ないものは最初から無いし書く必要が無い
高機能エディタのサポート無しでも書くのに困らない
逆に自動整形が効かない弱みがあるが

まあLispの場合は全てがS式であることが言語の力だから、あれは仕方が無い

Lisp系はある意味清々しいよな
演算子の優先順位も、構文解析の結合度も、全て自分で書くんだから
人間がパーザやってる感じがするが、それ故に優先順位の間違いは無い

スルーパス出すために
pass文があるんですね

>>705
hash と array しかないんだったら JSON で充分

結局pythonのコードはインデント狂わすウィルス出てきたら終りだね
空白だと一見気付かないから
なぜか上手く動かない
で対策も遅れる

空白文字部分を表示するエディタ使ってますが何か？

じゃあインデント狂わすウィルスが出てくるまでPython最強だね。

それなら、かっこ、コンマ、改行とかを狂わすウィルス作る方が効果的だろ

知らぬ間に意味が変わってるのがいいんじゃないか

そういうバグが一番たちが悪い。自分で間違ってるはずがないと思い込んでるところが一番発見しにくいからね。

メソッド内でself強制なのはわかるが、引数にselfは要らない

スレタイ

ただ、変に書きすぎると右にずれてきて見辛くなる

そういうときはモジュールか関数に吐き出す時期

改行抜けただけで崩壊ｗ

その危うさが楽しいw

Lispは括弧1個間違えると読み込み終了時に初めてエラーだとわかる。
最初に出てくるエラーはS式として括弧が足りない、多いというもの。
まず括弧の数を合わせないと構文が正しいかのチェックすらできない。
つまり修正に2工程掛かる。

Cはセミコロンが抜けたらその付近で構文エラーになり止まる。
これは文と式を分けている効果であり、良く考えて作られていると言える。

Pythonも文と式に分かれている以上、ある範囲内で何かおかしい、
ぐらいは判るんじゃないかと。

Lispには及ばないが、むしろC言語のセミコロン抜けは解りにくい部類
セミコロン抜けは抜けた行じゃなくて、次の行のエラーになるからね

次の行というか、文の終端記号ごとだよ。

HTMLから脈々と続くネットデファクトとも言えるデータ形式で
複数スペースを解釈しないんだから、pythonは不幸なんじゃないか。
python説明するWebページ作るのって苦労しない？

？

http://python.rdy.jp/

>728
2chのPythonスレでは&nbsp;や全角スペース、専ブラのレス参照を活用してることが多いね。
俺はスペース2つ→&nbsp;で置換してから投稿することにしてる。

ネットデファクト(笑)

PRE要素使えよ。

インデントのせいで２ｃｈにソース貼りにくいから、
宿題厨が沸かないのがいいな。

>>732
>>732
>>732

Web 頁作る件なら PRE でいいだろうし、python に限った話でもない
だだブログで記事を編集しなおしたら勝手に行頭スペースが詰められて焦ったことがある

掲示板とかでタグ認識しないところは<PRE>じゃどうしようもないんだけど…

だけど何

だからpython世界では、宿題のコードください(^q^)はいあげます(^p^)みたいなやりとりはＮＧってこった。

必要な情報だけ書けば問題ないだろ。

>737
どうしようもないんだけど、そういう場合にもPREって言うのか？と

んなことでいちいち思考停止してたら、AA職人の足下にも及ばねぇだろ。

>>738
ヒット

というか、self強制の件については我らが偉大なるGuidoパパ自ら回答してくれているので、まずこれを読め。
http://coreblog.org/ats/translation-of-why-explicit-self-has-to-stay

foo = C()
のとき、
foo.meth(arg) == C.meth(foo, arg)

である。

age保守

744

>>721
> ただ、変に書きすぎると右にずれてきて見辛くなる

そんな初心者カスコードを書けないように抑制する仕様だから。

右にずれすぎないようにするだけのために不自然な書きかえをするのは本末転倒だね。

つまらんこと気にする香具師は Python 使っていないで文句言うという法則

>>746
処理自体が不自然だから見直せって意味だろ。

処理はまちがっていない。まちがっているのは、本来なら正しい処理を
文法にあわせるためにいじる必要のある Python の方。

IF の後ろにひとつしか文が書けなかった昔の BASIC でプログラムを
書くために条件をひっくりかえしたりしていたのと同じこと。

正しい処理って何よ
ひっくり返しても正しく動くなら正しい処理だろ

>>749
ばか？

ネストを深くする方が正しいって、具体的にはどんな処理？

>>749
合ってる間違ってるの話じゃない。
それに、pythonに限らずほとんどのメジャーな言語ではネストが深くなると分かり辛くなる。

>>752
ブロック外の多くの変数を参照せざるを
得ないコード。

関数化したら引数の設定に一苦労。

class使えばいいじゃん
馬鹿なの？
死ぬの？

例えばWin32APIの各戻り値の判定コードをまじめに書くとifだらけになる
正常系をネストするか、逆転してエラーに落としていくか。
そういうことじゃないかと

アレ絶対APIの設計狂ってるよなぁｗ
ハンガリアンとかも狂気の沙汰だし

>>754
classの他にも、ブロック内に関数作る方法もある。

>>757
正しい設計だとどうなるの？

>>759
正しい設計を求め続けて、しかし商品としては売れない。

どうせCOMのような代物ができるだけだから諦めろ

>>759
fork, open, creat, brkみたいな最低限なシステムコールしか作らない。
システムコールだけではウィンドウ作ったりはサポートしない。

その結果、サーバクライアントモデルを採用した複雑奇っ怪なウィンドウシステムが出来上がり、
Win32APIでGUIアプリ作るよりもずっと悲惨な事になる

>ただ、食わず嫌いなんだろけど、pythonのインデントで〜っていう仕様が好きになれない。

python 使ったことが無い人はそう言うね
だけど python 使ってる人はそんなことは言わない
なぜだかわかるね？

仕様に付き合う覚悟が出来ているからであります！

>>763
うーん、宗教だからか？
入信者が学習すべき教義の文献は多いみたいだしね。

それならブレースだって宗教だな
信者多すぎ

インデントはするが、それを制御構造にすることに反感を抱いている人は、ブレース教の洗脳が解けない人。

もともとインデント教とブレース教両方の信者だったのなら、Pythonに移行するときに新しい宗教に入信する必要はない。

誤爆にすごい人気だ

やっぱり begin〜end が人気なんだな

pythonのインデントとlispの括弧は好きだが他は苦手

見た目とか書き易さとかはエディタでなんとかすべきじゃね？
っていつも思う

そろそろ3Dでソースを（ｒｙ

最終的にコードは常にインデントしてるからそれはいいんだけど
debug 中にインデントのレベルを変えて実行してまた戻すとかするのは珍しくない
ちょっとその辺は煩わしいと思うけどPythonメインに使ってる人は
その辺は気にならないって感じなのかな

＞debug 中にインデントのレベルを変えて実行してまた戻すとかするのは珍しくない

初めて聞いた

意味は分かる
デバグや実験目的で一時的なコードを挟んだり除去したりするときには
インデントとかどうでもいいので、整えるのがうざいということだろう

関数にすればええやん

それよりも、別のところからコピペで持ってきたのをインデント整えるのがめんどくさい

if 1:
　　コード
でいいじゃん同じレベルは同じインデントが必要なだけで
レベルが違ったらインデント深すぎな分には大丈夫だよ
ハードタブはソフトタブx4でカウントされてるみたいだけど

何それ、こわい。

> ハードタブはソフトタブx4でカウントされてるみたいだけど

8だよ

ソフトタブってふつーインデントレベル1段分のことを言うんじゃないの?
ハードタブを計るのはふつー空白の個数だと思うけど。

>>776
debug 中にテストするの一々新しい関数作れっていうのはもっとウザいな

インデントに文句言ってる香具師のほとんどは
食わず嫌い

俺は、インデントで制御構造を表せられるから、
python使ってる。
じゃなきゃ使わない。

Cが登場した頃に、構文が記号的すぎると言われた。
主に++, --, ?:, *, &などだが、{ }もその中に含まれていた。
begin endじゃまずいのかと…

そりゃCが登場した頃のALGOL系はBEGINやDO〜ENDでブロック表すのがほとんどだったからだろ

そりゃPythonの登場した頃のC系は{ }でブロック表すのがほとんどだったからだろ

結局そんなところなんだよね、反発なんて
慣習から色々言われるんだけど、最終的には割とどうでもいい

俺は蛇使いだが、しかし、インデントで制御構造表現するデメリットもあると思うぞ。

やっぱり、if-elseや、for/whileとかで、ブロックが長くなると、構造が把握しづらい。
そうならないように書くのが理想だけど、仕事のプログラムとかになるとやっぱり
そうもいかないってところも散見されるわけで。

あとからソースを整理、なんてときに、インデント間違って、エンバグしちゃうとか
ってしばしばあるw

そんな酷い職場でもPythonは使われるようになったんすね

>あとからソースを整理、なんてときに、インデント間違って、エンバグしちゃうとか
>ってしばしばあるw

引退しろ
同じプロジェクトに居たら首にする

>>791
それくらいのミスでクビにしてたら、
すぐに誰もいなくなる。ｗ

自分もちゃんとクビにするようにな。

http://twitter.com/yukihiro_matz/statuses/29317109670

yukihiro_matz: 英語圏でRubyとPythonを比較する記事を見ることが少なくなってきた
のは、RubyとPythonでクラスタが分離してきたからか。逆に日本語でRubyとPythonを
比較 する記事を見かけるのは国内でのPythonの地位が向上したからか。

　　　　　　　　　　　　 　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　 ／⌒　　⌒＼　　 |　　 |
　　　／（ ●） 　（●）＼　 !　　 !
　 ／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　 　 　 | 　／　＜こいつ最高にアホだお
　 ＼ 　 　　｀ ー'´ 　 　 ／／
　　/　＿＿　 　　　　　　/
　　(＿＿＿）　　　　　　/

　　　　　　　　　　　　 　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　 ／⌒　　⌒＼　　 |　　 |
　　　／（ ●） 　（●）＼　 !　　 !
　 ／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　 　 　 | 　／　＜こいつ最高にアホだお
　 ＼ 　 　　｀ ー'´ 　 　 ／／
　　/　＿＿　 　　　　　　/
　　(＿＿＿）　　　　　　/

>>95
やってみたらSyntax Errorになった

>>795
こうしたら動いたお!

result = []
indent = 0
for c in """
for i in range(10): {
if data[i]==3:
break
}else: {
print "NOT FOUND"
}
""":
    if c == '\n':
        continue
    elif c == '{':
        indent += 1
        result.append('\n' + '\t' * indent)
    elif c == '}':
        indent -= 1
        result.append('\n' + '\t' * indent)
    else:
        result.append(c)

exec(''.join(result))

ちょw

ttp://hibari.2ch.net/test/read.cgi/tech/1288342460/921

> for a in b:
> 　　while a < 100:
> 　　　　print '''なんとかかんとか
> ああだこうだ
> どうしたこうした
> '''
> このインデントの掻痒感はどうにかならないの？

こんな話題があったよオだが

>>798
その部分だけインデントが崩れるから、下記のように書きたいってことだろ？
俺も同じ理由でトリプルクォートは使わずに、文字列を1行ずつリストに入れて"\n".join(ls)してる

> for a in b:
> 　　while a < 100:
> 　　　　print '''なんとかかんとか
> 　　　　ああだこうだ
> 　　　　どうしたこうした
> 　　　　'''

一行ずつlstripする関数でも書けば？

いやそれでも良いんだけどね
ただ、それだけのために1こ関数書くのもなんだかなあって思うから
リストにしてjoinするって形のがよく使うかな

>>800
必要なスペースとそうじゃないスペースの区別はどうやって？

print re.compile('^ +', re.M).sub('',
         u'''なんとかかんとか
         ああだこうだ
         どうしたこうした
         ''')

print re.compile('^\s*\|', re.M).sub(
　　　'', """|
　　　|そんなもの
　　　|　　　どうとでも
　　　|　　""")

for a in b:
    while a < 100:
        print('''なんとかかんとか\n'''
              '''ああだこうだ\n'''
              '''どうしたこうした\n''')

for a in b:
while a < 100:
print 'なんとかかんとか'
print 'ああだこうだ'
print 'どうしたこうした'

てかソースを綺麗に見せるためにreモジュールを使うなんて愚の骨頂
うとぅくすぃソースのためにパホーマンスを犠牲にしてんじゃねぇよｗ

>>806
やっちまったなｗ

こういうことになるからインデントに反対　ならちょっと納得

たかだか数行のコードにパフォーマンスとか（笑）

>>806
みんな、気を遣って全角スペースを入れていたのに…

パフォーマンス云々の前に>>803-804は読みにくいだけで
エレガントな書き方だとは思えない

>>798がpythonに特有の問題みたいになってるけど
どの言語で書いても暗黙的にインデントを使うわけだから
大概そうなるわな

py豚スレだけスペース削除を廃止してくだpy m(_ _)m

HTMLのソース見れば分かると思うが、スペースが削除されるのは
あなたが使っている表示用ソフトウェアの仕様の問題だ。

>>812
それは知らんかった
ところでちゃんと に置き換わってるレスもあるけどどういう仕組み？

&nbsp;だろ
  foo

&nbsp;

＆amp;と＆nbsp;
↑使えたんだこれ
ねらー歴10年目の衝撃

㈱㍊㊾
このへんは板の設定による。

print '''|
　　　|そんなもの
　　　|　　　どうとでも
　　　|　　'''.replace('^\s*\|', '')

専ブラでV2Cとか使うとコンテキストメニュー使って＆nbsp;に変換できる

>>798
Cで書かれたオープンソースのコードを読んでみると
printfをゴリゴリ書き連ねてるのが割と多いよ
オレはこの書き方が一番読みやすいと思う。ソースと実際の
表示が視覚的に同じようになるから↓
>>804あたりのはネタとしても実際にどんな表示になるのか
わかりにくいのがよろしゅくない

print "ドラえもん"
print " ・2112年9月3日生まれ"
print " ・ドラ焼きが好き"

print "ドラえもん"
print "    ・2112年9月3日生まれ"
print "    ・ドラ焼きが好き"

ム板なんて無い方がいいと思うんだけどね。
ここを見ると、2ちゃんねるの悪い面が凝縮していて
気分が悪くなってくるよ・・・
前はたまに見てたけど、今はこのスレ見るのやめたよ。

http://yuzuru.2ch.net/test/read.cgi/ana/1293674248/394
> 394 ：名無しがお伝えします：2011/01/26(水) 22:36:40 ID:1RQz8hyq0
> ラウンジなんて無い方がいいと思うんだけどね。
> あそこを見ると、2ちゃんねるの悪い面が凝縮していて
> 気分が悪くなってくるよ・・・
> 前はたまに見てたけど、今はあのスレ見るのやめたよ。

ネタ元わかるのかｗ

re 使うやつが一番読みやすい俺。

インデントのためだけに print たくさん書く奴は DRY とか知らんのか。

まああんまり長くなるようなら普通にtemplateだよな

>インデントのためだけに print たくさん書く奴は DRY とか知らんのか。
printを書き連ねるのがDRYに反するという主張なら
嘲笑を超えて爆笑だなｗｗｗ

>>827
頭の悪い奴って覚え立ての言葉を盾にする傾向があるよね

コピペでプログラミングする層と
やたらとprintを書き連ねる層はほぼ一致する

ソースはオレの脳内統計ね

　　　　　　　　　　　　 　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　 ／⌒　　⌒＼　　 |　　 |
　　　／（ ●） 　（●）＼　 !　　 !
　 ／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　 　 　 | 　／　＜こいつ最高にアホだお
　 ＼ 　 　　｀ ー'´ 　 　 ／／
　　/　＿＿　 　　　　　　/
　　(＿＿＿）　　　　　　/

妄想を根拠に断定するとはけしからんヤシじゃ

sageでちちくりあってじゃねーよ

>あってじゃねーよ
>あってじゃねーよ
>あってじゃねーよ
>あってじゃねーよ
>あってじゃねーよ

ｗｗｗ

なにこれ？
琴線に触れたの？

>sageでちちくりあってじゃねーよ
ならその誤字レスをageればぁ？ｗ

>>818と>>820は新しくスレッドを立てて、
そっちでやってね。

pass

>sageでちちくりあってじゃねーよ
なにこれ？
キーボードからnのキーが外れたの？

reを使うくらいなら、

print("abc\n"
　　 　"def\n"
　　　 "ghi\n")

の方がよくないかと思ったが、
既に出てたな。

./django/utils/termcolors.py
36 print colorize('first line', fg='red', opts=('noreset',))
37 print 'this should be red too'
38 print colorize('and so should this')
39 print 'this should not be red'
./django/contrib/gis/utils/ogrinfo.py
25 print "data source : %s" % data_source.name
26 print "==== layer %s" % i
27 print " shape type: %s" % GEO_CLASSES[layer.geom_type.num].__name__
28 print " # features: %s" % len(layer)
29 print " srs: %s" % layer.srs
./django/core/servers/fastcgi.py
106 print >> sys.stderr, " Unable to load the flup package. In order to run django"
107 print >> sys.stderr, " as a FastCGI application, you will need to get flup from"
108 print >> sys.stderr, " http://www.saddi.com/software/flup/ If you've already"
109 print >> sys.stderr, " installed flup, then make sure you have it in your PYTHONPATH."

reを使う奴は正規表現を覚えたての初心者だろｗ
どうしてもprint1個ですませたいなら変数を使って文字列を連結して
最後にprintすればよろし

個人的には最初ので慣れてるけど

print u"""
111
　222
　　333
"""[1:]

とか。

そもそも、その手の文字列はリソースファイルとして独立させておくか、
せめてモジュールグローバル変数で定義しとけ。
ソース中に直値で埋め込んだりするから、そういう姑息な手が要るんだYO！

BLAME_MESSAGE="""アホ
こうやってグローバルで書けば
インデント気にせずに済むだろが"""

class Trash:
　 def say():
　　　print BLAME_MESSAGE

ネ申あらわる

俺ならこう書くな
MESSAGE = ["おはよう",
　　　　　　"こんにちは",
　　　　　　"こんばんは"]

for i in MESSAGE:
　　print i

>>845
せめて、こうしろ。
MESSAGE = '\n'.join([
　　"こうすりゃ",
　　"joinは一度だけしか",
　　"評価しなくてすむ"])

if you.dontUnderstand(this.way):
　　print MESSAGE

こういう、すぐ捨てる、変更の必要もないiterable作るとき、tupleかlistどっちがコスト少ないんだろ？

むしかえすけどメソッドの第一仮引数にわざわざselfを書くことが強要されていることを
神扱いしてるひとってなんなの？

>>848
神扱いしてる人は、見たことないが、いたら俺もなんなの？って思うだろうなぁ。
けれど、あれは、書かない方が不自然だよ。　そしてこのスレはインデントのスレだからスレ違いだよ。

引数はともかく
メソッド内でインスタンス変数を使うときにself.付けてるうちに
ソースがself.だらけになって気持ち悪くなることがある
インスタンス変数にしなくてよい変数にまでself.付けてしまったり
特にGUIのフレームワーク使ってるときにその症状が出る傾向が強い

>>846
これ書き込んだすぐに、思いついたんだが、
こういう最適化っていちいち気にしながら
みんな書いてるの？

とりあえず、ざっとつくって必要そうなとこだけC言語で作り直すんだが。
パフォーマンスとか気にするなら最初からC言語で書くな。

>>848
おかげでメソッドと関数を相互変換できる。

>>851
そうすることでコンマ何ミリ秒遅くなるとか、そういうことは考えてないし、何度も呼び出される処理でもない限り、考えるのは不毛だと思う。
パフォーマンスの低下ってより、明らかに無駄なものがコード中に転がってたら気持ち悪いから排除したいだけ。

リストよりタプルの方が生成コストが小さいとわかっていても
よほどデータが多くなければ，()を使うタプルより[]を使うリストをよく使う
同じ理由でジェネレータ式よりリストの内包表記

>インスタンス変数にしなくてよい変数にまでself.
self明示しない言語の方が手間がかからない分、
無駄にインスタンス変数作ってしまいがちのような気がするんだが

へ？

変数の話はよそでやれ

Pythonってワンライン記述できる？
コマンドラインだけで簡単な処理を行いたい場合ってどうするわけ？

>>858
出来る
http://wiki.python.org/moin/Powerful%20Python%20One-Liners

できるけど向かない。
execとエスケープシーケンスがある限り、Pythonでできることは全部、一行でもできるが。

>>798
今さらかもしれないけど、inspect.cleandoc()使えば楽だよね、これ

>>> from inspect import cleandoc
>>> cleandoc("""abc
...          def
...          ghi
...          """)
'abc\ndef\nghi'

先頭行もインデントするならtextwrap.dedent()も使える
(こっちは先頭と末尾の改行を保持する)

>>> dedent("""
...        abc
...        def
...        ghi
...        """)
'\nabc\ndef\nghi\n'

すっきりしないね

きもいな

>>846のほうが30倍ぐらいマシに見えるのは何故だろう？

cleandocの方はdocstringと解釈が一緒なので、そんなに違和感ないけどなー
数箇所くらいじゃimportしてまで使う気にならないので、あんまり使う機会はないけど
インデントが気になっても、ほとんどの場合>>840か>>843で間に合う

インデント強制ってなんだよと思っていたが、慣れると結構良い物だ。

後から外側にループを追加するのが面倒くさい

漏れはタブ文字ではまった

俺はエディタの設定でタブ文字表示させてる

>>867
そんなのエディタの工夫でどうにでもなる。
emacsのpython-mode楽だぞ。

emacsって早く滅びないかな？

ブロックがカッコだと、vimで%押したら対応するカッコまで飛ぶからv%>でブロックごとインデントあげられるんだが。
Pythonの場合、どうすればいいの？　vim使うのやめるとかそういうのなしで。

end

オフサイドルールは、

・ワンライナーと相性が悪い
・ウェブページのテンプレートライブラリと相性が悪い
・プログラムサイズの圧縮ツールと相性が悪い
・プログラムの難読化ツールと相性が悪い
・プログラムの自動整形ツールを頼る事が出来ない
・老眼と相性が悪い

・コピペが面倒
・後から大外にブロックを追加するのが面倒
・エディタを選ぶ

・構文が BNF で表現できない
・BNF 用のパーサーが利用できない

・言語開発者の頭が悪い
・言語利用者の頭も悪い

実際PythonってOOP理解できない低能の逃げ道に使われてるんだよな
おまえらの書いたゴミと一緒に氏んでくれって思うわ

>>876
これ困るのって限られるだろｗ

>>877
Rubyなんとかと違ってむしろモジュール化とかクラス化とか後からリファクタリングし易い言語なんだぜ

Python 使いってやたらと Ruby を意識するよなw
世の中もっと沢山言語があるのに...

Ruby 使いってやたらと Python を意識するよなw
世の中もっと沢山言語があるのに...

それは無理があるわw

皮肉は筋が通ってないと意味無いんだぜ

>>877
バカに、バカでも使えるものが作れるとは思えないし、
スレタイも読めない奴に、人がバカか否か見抜けるとは思えない。

掲示板でバカ、バカ書いてる人は、どのくらい頭が良いのかな?

>>884
もし、僕のことを言いたいのであれば。
「頭が悪い」と「低能」を使い分ける意義が分からなかったし、めんどくさいので「バカ」に統一しただけだよ。

言葉尻だけ捉えてどうこう言うようなバカにはなりたくないものだ。

言葉尻w

「バカって言うやつがバカなの」って子供の頃に聞いた気がするが、何だかんだで上手い言葉だよな

人がバカと言わずにはいられない時って、どんな時だろうな...

またruby厨の荒らしか

角電池

煽るだけしか能が無いやつにゃ、制御構造なんてあったもんじゃないから、カッコでもendでもインデントでも何でも一緒だな。

実際掲示板にいる馬鹿な奴は馬鹿だからな。

そしてそういう馬鹿ほど >>887 みたいに思ってるが、実際のところ馬鹿だ。

恋人に耳元で囁かれてみろよ。「バ、カ。」もいいもんだ。

愛情表現ならいいけど、罵倒はちょっとな・・
しかも直接的な言葉を使った罵倒は、大人になると自分へのダメージの方が大きい

ｐｙてょんがRuby様より優れているところって何？

正直2.0の完成度を高める為なら、1.9.9xxとか９００回以上リリースしまくってもいいとは想うw

中学生のコミッタがいないところかな

つまり、特に無いって事?

エディタを半角70文字で右で折り返す設定にすると

「右に折り返す」って、左から右に書く言語では難しくないか

「右に折り返す」なんてどこにかいてあるんだ

インド人禁止

読み間違えました、本当にごめんなさい

一行が長いと折り返されるからインデントが崩れるというか見辛くなる
みんな全画面表示で書いてるの？

適当に折れば

見辛き　コードかな

長い行ってそんなにあるかな？
適切に処理を分けて、モジュールを分けて、としてれば
たまーにしか出てこないと思うんだが

print("スライムがなかまにはいりたそうにこちらをみているけどどうするよ...")
と
print("スライムがなかまにはいりたそうに\
こちらをみているけどどうするよ...")
と
msg0 = "スライムがなかまにはいりたそうにこちらをみているけどどうするよ..."
print(msg0)
のどれが良いですか？

print('''
スライムがなかまにはいりたそうに
こちらをみているけどどうするよ...
'''.replace('\n', ''))

print('''
______スライムがなかまにはいりたそうに
______こちらをみているけどどうするよ...
______'''.replace('\n', ''))
のようにすることは出来ますか？

print("スライムがなかまにはいりたそうに"
      "こちらをみているけどどうするよ...")

PEPに従うなら、あんまり長い行はないな。

インデントでしかブロックを表現できない言語で、インデントが崩れたら致命的だからな。

pythonのインデントに文句言う香具師はpython使ったことが無いアホがほとんど

セリフとか長くなるものは別に書いておいて、
それをインデックスで参照するようにすればいいのかな？

Pythonに限らず、別の言語でも普通そうなるんじゃないか？

>>914
>>874-876

>>908
一番下

外国で人気があるようだけどUSキーボードでコロンを入力する時に
シフトキーを押すの面倒じゃないのかな

perlみたいに$%&いらんからな

だからコロンを使ってみたくなっちゃったのか

一方rubyは@を使った

http://docs.python.org/faq/design.html#why-are-colons-required-for-the-if-while-def-class-statements

パーサはコロンなんて必要としてないもんな

http://anond.hatelabo.jp/20080806031715

if a == b: print 'true'
else: print 'false'
みたいに書くときもコロン無しを許可したらインデントと混在出来なくなったってことじゃないのかな

何かそれ Python らしくない

Python 的には
print 'true' if a == b else 'false'

Python3000は惜しかったな、次の4000に期待か

>>928
つまりコロンなんて無くても良かったって事か

動作が先にきて条件が後にくるのは後出しじゃんけんみたいで嫌だな
結論を先に書くのは英語っぽいけど

>>928
print a == b
で良くね？

a = 0
b = 1

if a == b:
print("フラグが勃った")
else:
print("バッドエンド")

print("フラグが勃った") if a == b else print("バッドエンド")

print(a == b)
↑これだといつまで経っても「フラグが勃った」と表示されないよ。

えろげでも作ってるの？

t
e
s
t

結論は出たみたいだから埋めてくかな

ume

python最強

ume

hara

うめ

千里め

.

なんだここは

このスレが埋まったら、オフサイドルールの問題点の話が本スレに持ち込まれる気がするんだが

次スレ立てればいいだろ

勢いが1月で終ってるから誰も来ないでしょ
きのこスレとか再利用すればいいよ

つ 【オフサイドルール】プログラミング言語文法総合スレ【ダングリングエルス】

そのスレどの板にあるの？

次スレの名前候補だろ。
多分長すぎで無理。
【Python】オフサイドルール【Haskell】
ぐらいでいいんじゃね？

いやまて、スレ立てられる人いるのか？
このまえ全員の忍法帖焼かれたでよ

>>950
継続スレだとわかるようにする方が良いと思います。

【Python】オフサイドルール Part2【Haskell】

オフサイドルール（字下げによってブロックを示す規則）について議論するスレです。
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%95%E3%82%B5%E3%82%A4%E3%83%89%E3%83%AB%E3%83%BC%E3%83%AB

前スレ
Pythonに見られるインデントによる制御構造の是非
http://hibari.2ch.net/test/read.cgi/tech/1169473442/


>>951
●持ちならテストスレでLv=10にレベルアップするのに30分しかかかりません。

【Python】オフサイドルール tab2【Haskell】

>>951
普通に毎日カキコしてたらこのくらいにはなってるよ

この前たぶん別のスレ立てたせいかしばらく立てられない
どのスレ立てたのかすら覚えていない

>>953
【Python】オフサイドルール 2桁【Haskell】

のが短くて良くね？

俺は年寄りだからオフサイドルールというと Python でも Haskell でもなくて
Occam なんだが……

Occam は Python とちがって、文の途中でも演算子などのあとで改行していいし、
ここでしょっちゅう話題になっている複数行にわたる文字列もインデント可能。
オフサイドルールに関しては Python よりよく考えられていると思う。

オフサイドルールというのは標準的な用語なんでしょうか？
このスレではじめて知ったものですから。

プログラミング言語　文法　オフサイドルール　でググると良いよ。
自分で調べる事が出来る内容ですから。

MSDN の F# のところに詳しく書いてありました。

これ ； デリミタっていうんだけどさ、よく打ち忘れるよね
Rubyだとつけなくてよくなるんだけど
土方が何をいっても

天使さん戻っておいでよ

>>957
しかし、ここではPythonやHaskellのが有名だからスレタイとしては入れにくい
別に、PythonやHaskellに限ったスレじゃないから、一言入れればその言語の話をしたっていいのよ

Haskell はオフサイドルール強制じゃないのよね

そうしたら Python 特有のオフサイドルールを扱うべきということ？

是非が問われるのは Python だけじゃないかな
Haskell はインデントに縛られている訳じゃないから

Python 専用オフサイド part2

ume

てか次なんて立てずともLLバトロワ辺りでやればよくね

python最強

気にしてるのは Python 使いだけだからね
他の人からすればどうでも良いこと

タブ文字あかんのか...

スペースを使えばいいよ

そろーり

潜行中

さげ

すーっ

ぱ

まん

こ

〓∋ ((i))

pass

(Ａ∪Ｂ)

Ａ⊇Ｂ

True || False

Ａ Ｂ

で、次スレのスレタイは、
【Python】オフサイドルール 2桁【Haskell】
で異議ありませんか？

ええんじゃないの？

〓∋ *

いらないでしょ

あったほうがいいな

Haskellを入れる入れないの話はどうなったの？
この問題って Python 特有なんでしょ？

http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%95%E3%82%B5%E3%82%A4%E3%83%89%E3%83%AB%E3%83%BC%E3%83%AB

【Python】オフサイドルール 2桁【Haskell】
http://hibari.2ch.net/test/read.cgi/tech/1310654456/

>　インデントでプログラムの意味が変わる offside rule はいらないですよ。

実際使ってみると気にならないレベルだとわかる
いらんと言う香具師は素人

●持ちならテストスレでLv=10にレベルアップするのに30分しかかかりません。

http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%95%E3%82%B5%E3%82%A4%E3%83%89%E3%83%AB%E3%83%BC%E3%83%AB

うめ

ume

【Python】オフサイドルール 2桁【Haskell】
http://hibari.2ch.net/test/read.cgi/tech/1310654456/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。