12/02/18 19:19:45.30
>>916
> Pythonは多重継承あるから、勝手に継承元決められるより
> 親クラス明記のが楽かも
ダウト
Python2でのsuperは親クラスじゃなくて自クラスを指定する
信者乙
＃いやこの程度を間違えるなら信者ではないかも？
919:デフォルトの名無しさん
12/02/18 19:22:06.73
>>916
親クラスを指定するんじゃないんだよ。それなら百歩譲って理解できる
そうじゃなくて自身のクラスを書かなきゃダメなわけ。例えばこんな感じで
class C(B):
def meth(self, arg):
super(C, self).meth(arg)
全く意味不明だろ？w
Pythonユーザの俺でも擁護できんわwww
(なお、Pythonのメソッド呼び出し obj.meth() は C.meth(obj) と等しいので
親クラスを選んで呼ぶのは普通に出来る）
920:デフォルトの名無しさん
12/02/18 19:31:45.45
>>918-919
Ω＜ナ、ナンダッテー
いや普段使わない言語に俄か知識でテケトーな事言ってスマンカッタ
921:デフォルトの名無しさん
12/02/18 19:36:15.72
python使っててそういうコードに出くわした記憶がない
922:デフォルトの名無しさん
12/02/18 19:37:10.33
>>912
>PythonのsuperはPHP以下
そんなこというと、Python信者が暴れるだろうが―！
URLﾘﾝｸ(twitter.com)
> Pythonだと、プログラムを綺麗にしようとするモチベーションが働くけど、
> perlやphpではそういったモチベーションが働きにくくてやっつけコードに
> なるのは、俺の個人的な問題なのか、ある程度言語自体が抱えている問題なのか？
URLﾘﾝｸ(twitter.com)
> php使うとcometとかWebSocketとか対応が難しいし、HandlerSocketの性能も引き出せないし、
> Fluentのphpクライアントも他の言語で普通にできているバッファリングが普通には出来なくて
> 苦労してるらしいし、
923:デフォルトの名無しさん
12/02/18 19:38:52.74
URLﾘﾝｸ(twitter.com)
> 「新しい技術に挑戦する」ことを奨励する企業がphpばかり使ってるのは問題だよね。
Python信者の発言こそ問題だけどな。
924:デフォルトの名無しさん
12/02/18 19:47:15.28
大昔にもツイッターのコピペばかりしてる奴がいたけど復活したのか
925:デフォルトの名無しさん
12/02/18 20:56:41.67
>>915はアンチPythonのふりをしたPython信者
自演キモ
926:デフォルトの名無しさん
12/02/18 21:30:44.44
>>909
> （ただし、デコレータは一種のマクロだから「Rubyとは」相性が悪いように思う）
デコレータはただの高階関数（に対する構文糖）
Rubyと相性が悪いとすれば、それは高階関数と相性悪いってこと
927:デフォルトの名無しさん
12/02/18 22:59:25.08
>>905
もっともなご意見有り難う。そんな事言いだしたら、PerlだってMooseで型制約出来るもんな。切りがない。
928:デフォルトの名無しさん
12/02/19 00:18:28.13
URLﾘﾝｸ(twitter.com)
> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
> 察してください。
ワラタｗ
Python信者が言い訳しとるｗｗ
929:Python信者
12/02/19 00:49:15.04
>>918
馬鹿は黙ってろ
>>912
どうしてもPython2でその書き方が嫌なら
super(ClassName, self).method()
の代わりに
SuperClassName.method()
でもいい
さらに
どうせインスタンス作った後はsuper変えることなんてなさそうだから
__init__の中で
__super=super(ClassName, self)
とした上で
__super.method()
って書いても良い
何でobjectクラスの中でそれが定義されてないのかって突っ込むなら
Railsのまねで
object.__super=
930:デフォルトの名無しさん
12/02/19 08:01:58.01
>>929
objectに属性追加出来ないだろ
本当にPython信者か？
931:デフォルトの名無しさん
12/02/19 08:15:29.58
>>929
>どうしてもPython2でその書き方が嫌なら
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
>でもいい
ださいことには変わりないけどな
>さらに
>どうせインスタンス作った後はsuper変えることなんてなさそうだから
>__init__の中で
>__super=super(ClassName, self)
>とした上で
>__super.method()
>って書いても良い
素人考えだな
それは継承を2段階行ったら破綻するやり方
932:デフォルトの名無しさん
12/02/19 08:29:06.48
Pythonはこんなにダサいのに
いざコードを書かせるとRubyが圧倒的にダサいのは何故だろう？
933:デフォルトの名無しさん
12/02/19 08:35:15.15
>>932
信者だから
934:デフォルトの名無しさん
12/02/19 09:07:08.15
>>932
まったくの主観で笑えるｗ
Python信者がんばれ！
935:デフォルトの名無しさん
12/02/19 09:11:41.50
>>928
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
disってるという自覚はあるのね
信者って、そういう自覚がないままに行動してると思ってた。
>>929
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
SuperClassName.method(self) の間違いだろ
信者がそんなミスするなよな
936:デフォルトの名無しさん
12/02/19 09:29:05.87
>>934
Ruby信者には>>898>>914がダサくないの？
937:デフォルトの名無しさん
12/02/19 09:34:49.37
>SuperClassName.method(self) の間違いだろ
>信者がそんなミスするなよな
それはもちろん気付いてたが
単に()をmethodを代表するものとして付けただけだから
938:デフォルトの名無しさん
12/02/19 10:49:38.33
>>937
苦しーｗ
そんな小さなミスすら、認めようとしないのか
こんな便所の落書きですら自分の体面を保とうとしているとは恐れ入った
939:デフォルトの名無しさん
12/02/19 10:50:09.44
>>926
もしもPythonが高階関数との相性が良いのなら、
高階関数の合成演算(の構文糖)であるメソッドチェーンを
何の不自由も無く使えているはず
でも、現実にはPythonでのメソッドチェーンは使い物にならないから
(あるいは用途が極めて限定されてしまうから)、
「Pythonは高階関数との相性が悪い」とも言えてしまう
だから、>>909では、デコレータがRubyと相性が良くない理由を、
「デコレータが(構文糖である)マクロであるため」と書いている
分かるかな？
940:デフォルトの名無しさん
12/02/19 11:33:07.96
>>939
その主張は「Rubyが高階関数と相性が悪い」の反論になってない
あとデコレータはLipsマクロほど強力じゃない。所詮はただの高階関数
941:デフォルトの名無しさん
12/02/19 11:35:26.31
＞＞936
Rubyもださいね。Pythonのsuperと同じくらいださい。
942:デフォルトの名無しさん
12/02/19 11:38:29.73
>>940
反論になっていないのなら、その理由をkwsk
理由なき主張は、単なる主観だ
943:デフォルトの名無しさん
12/02/19 11:39:59.95
>>942
なんで高階関数に過ぎないデコレータがRubyと相性が悪いの？
もう何度も繰り返してるけどデコレータは高階関数だよ？
「マクロだから」的な反論は間違いだからね
944:デフォルトの名無しさん
12/02/19 11:47:42.48
間違っているのはあなたです。
デコレータのメカニズムは高階関数ですけど、@ほげほげ、という記法は構文糖です。
この構文糖があるからこその「デコレータ」であって、この構文糖がなければ、
デコレータでもなんでもないただの高階関数です。
945:デフォルトの名無しさん
12/02/19 11:49:43.28
お前ん中ではな
946:デフォルトの名無しさん
12/02/19 11:50:08.52
>>944
じゃあ「ただの高階関数」なら使えるってことだよね？
だったら高階関数を使って>>914みたいなダサいコードを
もっと洗練させてよ
直視に耐えないレベルでダサいから
947:デフォルトの名無しさん
12/02/19 11:52:07.09
自分が理解出来ない ＝ ダサい
948:デフォルトの名無しさん
12/02/19 11:57:15.37
>>943
単なる高階関数に過ぎないデコレータ的な機能は、
(Pythonと違って)高階関数との相性が良いRubyであれば
ユーザコードで書ける
(たとえそれが>>898>>914のようにダサいとしても....)
でも、(構文糖である)デコレータ構文そのものの導入は、
ただでさえ複雑なRubyの構文を一層複雑にさせるから、
採用される見込みはないだろうな、という話
関数アノテーションについては、(たとえ構文の追加が必要であっても)、
ぜひとも導入を検討してもらいたいと個人的には思っているけどね
949:デフォルトの名無しさん
12/02/19 11:58:20.06
>>944
Pythonを知らなくてデコレータをマクロだと思ってたんだろ？
指摘されてから「高階関数だって知ってたし」とか笑えるw
じゃあもう一回聞くけど、何故Rubyとデコレータの相性が悪いんだ？
まさか「構文糖だから」か？
950:デフォルトの名無しさん
12/02/19 11:58:53.21
まあ、そもそものRubyの構文がわるいんだろうな。
行き当たりばったりで作ったから、
新しい機能を入れる余地がない。
あー、また互換性切り捨てか。
951:デフォルトの名無しさん
12/02/19 12:02:22.50
>>949
>>948を嫁
952:デフォルトの名無しさん
12/02/19 12:03:36.94
>>950
>行き当たりばったりで作ったから、
そのとおり、Pythonの関数型プログラミング機能と同様に、
行き当たりばったりだね
953:デフォルトの名無しさん
12/02/19 12:08:54.56
>>950
> 行き当たりばったり
> 互換性切り捨て
新旧スタイルクラスに3.0と、Pythonも大概だと思うが…
954:デフォルトの名無しさん
12/02/19 12:33:10.84
950は、よりよい言語にするためだったら互換性は切り捨ててもいいという、
最近のLL系言語に蔓延している風潮それ自体を批判しているんだよ
冒頭のRubyは飾りです、デコレータだけに
955:デフォルトの名無しさん
12/02/19 12:34:34.04
>>928
>URLﾘﾝｸ(twitter.com)
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
>> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
>> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
>> 察してください。
さんざん他の悪口を言っておいて、謝りもせず、なにが「察してください」だよ。
自分を追いつめるためなら何を言ってもいいと思ってんのか？
Python信者クズだな。
956:デフォルトの名無しさん
12/02/19 12:35:22.33
pythonのデコレータ自体は高階関数だけど、
@なにがし、はデコレータで関数を置き換える別の機能だと思うけど、、、
957:デフォルトの名無しさん
12/02/19 12:42:37.21
>>955
このスレのPython信者と一緒だね
958:デフォルトの名無しさん
12/02/19 12:46:02.17
>>954
最後のオチ、ワロスw
959:デフォルトの名無しさん
12/02/19 12:47:35.87
>>956
シンタックスシュガーだね
960:デフォルトの名無しさん
12/02/19 13:16:12.46
デコレーションケーキ
961:デフォルトの名無しさん
12/02/19 14:07:40.29
構文論と意味論がごっちゃになるバカとか、このスレにふさわしい隔離対象じゃあないか
962:デフォルトの名無しさん
12/02/19 14:08:29.48
LL ではない重量級の言語は何メインで使ってる？
LL だけって人もいるかもしれないけど、大抵は重量級と LL の両方使うでしょ。
組み合わせに傾向が出たりしないかな？
自分は C と Python です。
963:デフォルトの名無しさん
12/02/19 14:21:02.32
>>961
暴れているガキのことか？
うーん、いくらここが隔離スレだとしても勘弁して欲しい
ガキのお守りは疲れるから
964:デフォルトの名無しさん
12/02/19 14:24:47.80
>>962
漏れは C と Ruby
ただしどちらの言語ともプラットフォームは UNIX(Mac or Linux) だけど
965:デフォルトの名無しさん
12/02/19 16:10:41.76
「LL ではない重量級の言語」ってのがよくわからんけど、
Rubyや、Perlっぽい言語以外、という分類なら、CとかHaskellとか。
Haskellは慣れからくる惰性で使ってるだけだから、OCamlないし
遅延評価が必要ならもっと別の何かでも構わないと思う。
966:デフォルトの名無しさん
12/02/19 18:11:06.40
>>948
仮に@なにがしの構文糖が使えないとしても、>>825のコードは殆ど冗長にならない
def f(x:int, y:int) -> int:
return x + y
f = typecheck(f)
def g(x):
print(x)
g = validate(x=lambda x: -1 < x < 1)(g)
高階関数と相性の良いRubyなら>>914はもっと簡潔に書けるでしょ
ASSERT.kind_of を毎回書くんじゃなくて別のメソッドに隠蔽すべき
967:デフォルトの名無しさん
12/02/19 20:45:16.47
Rubyのメソッドは一級市民じゃないので高階関数とは相性悪いです
デコレータをRubyでやるなら動的なメソッドの再定義になりますね
元のメソッドを別名にしてそれをラッピングしたメソッドを同名で再定義します
def foo(x,y) x+y end
type_assersion(:foo, Integer, Integer)
見たいなのは実現可能です
順序を逆にして
直後に定義されるメソッドに対するデコレータみたいなのも書けなくはありません
type_assersion(Integer, Integer)
def foo(x,y) x+y end
ググって見つけたところだと
type_assersion(Integer, Integer) do
def foo(x,y) x+y end
def bar(x,y) x-y end
def baz(x,y) x*y end
end
って感じのがありました、これはRubyっぽい気がします
わざわざ型をチェックしたりする必要性はよくわかりませんね
そんなのは仕様とテストに書いてあれば十分な気がするので
968:デフォルトの名無しさん
12/02/19 21:28:50.10
>>964
unix環境でcを使うなら当然ながらgdbは必須なので、
gdbの拡張用スクリプトに公式的に選ばれたpythonつかっといた方が
幸せになれるんじゃなイカ？
個人的な考えでは、gdbの拡張用スクリプトは、luaかguileにすべきだった。
インデントが構文の言語は、対話環境でイジるの面倒杉だし、OOPとしてのpythonは失敗策。
あれなら、まだperlを採用した方がマシ
s-expなんてemacsがあってはじめて幸せになれるようなもんで、
インタラクティブな操作に向くとは到底ながら思えないけれど、
デバッガにはgnu公式のスクリプトを採用した方が組織としての一貫性があった。
ソフトウェアに永遠の命をなどとスローガンを掲げているわりに連中は自らその道を外れた。
ここのところ話題に挙がらない後発のgroovyって流行ってんのかな？
mozillaのrustといい、perlのようなものから
rubyのようなものを生み出した功績は素晴らしいと思う
969:デフォルトの名無しさん
12/02/19 21:44:06.10
>>968
元UNIX系だがgdbなんてほとんど使ったことのないオレが通りますよ。
（カーネル空間なんでgdbはパニックダンプ解析でしか使えないし・・・。）
関わって多言語は、
C(コーディング)、Sparcアセンブラ（デバック時）、Forth(レビュー対象)。
今はPerl、PHP、Javascript、Java、ActionScript、VBA、SQL、色々やってますが、PythonとRubyは未経験でつ。
970:デフォルトの名無しさん
12/02/20 00:04:01.82
Klabっていつの間にかソーシャルゲーム屋になってたんだな。