Pythonは同じ事するのにforと内包表記の2つの方法が
なんで同じことをするのに違う方法があるのでしょうか?
Pythonの哲学に反していますよね 一般的に知られてるPythonの哲学ってのは
後付けの言い訳だから真に受けるほうが間違ってる
実用的な意味や使い分けの慣習なんかを理解したほうがいい 見た目同じforでもスコープの扱い違うのが糞
継ぎ接ぎだらけの糞言語 文と式だから根本的に違うじゃん(ついでに速度も違う)。
そんなんより、map・filterの方が用途として完全に内包表記とかぶっているわけで。 >>5
根本的に違うかどうかは関係ない
Pythonは人によって書き方が統一できないのが問題 書き方を統一させるのは言語の役割じゃない
それをあたかも言語の役割であるかのように
勘違いさせるポエムをありがたがってるのが問題 >>1
「最善の方法が1つだけある」
って話なんだが
「方法が1つだけある」
って解釈してPythonガーとか遠吠えしてるバカ乙 >>8
Pythonで最善のフレームワークを教えて下さい >>8
あのポエム of パイソンでもさすがに「最善の方法が1つだけある」なんてバカなことは言ってないぞ >>9
最善の方法は実際に使ってみることだよ
フレームワークに要求するものは人によって違うからな
>>10
PEP20:
There should be one-- and preferably only one --obvious way to do it. >>11
え?最善の方法が一つだけしか無いなら
使う前でもなく答えられるはずだよね? >>12
2行目読めないの?
要求仕様って聞いたことないのか?w >>13
だから同じことをするのに複数の方法があるんでしょう? 要求によって、どの方法を使うか決めるなら
他の言語と何も変わらないよね まあでも、そう言っちゃうと There's More Than One Way To Do It. な perl も
最善なやり方はそのうちの一つかもな。 一貫性があれば哲学だと思うけどね
これはないけど、あれはあるって状況だと
単に実装がめんどくさかっただけだと思うね
この機能は重複するけど、面白そうなので作ってみた(内包表記)
この機能はあれば便利だけど、作るのがめんどくさい。ifでやって
そして後付で重複する機能は作らないといってるだけだろう
そのせいでよりよい方法が採用できないでいる Pythonで確実に言えるのは、誰が書いても同じようなコードになるわけではないってことね
そりゃ同じことを実現するのに複数のライブラリやフレームワークがあるのに
同じようなコードになるわけがない >>20
最善の方法なんて無いよ。
やり方が複数あるのだから、それに応じてやり方は変わる Pythonの誰が書いても同じようなコードになるというのは
単にインデントが揃う。という程度のものだと思ったほうがいい
コードフォーマッターをかければコードが整形されるでしょ?
あれと同じ >>15
同じことをするのに複数の方法がないとは書いてないけど?
>>8から読み直して理解できないなら諦めたほうがいいよ >>17
だいたいの人が考える最善な方法を1つにするってことね
Perlの
if(!a){…}
と
unless(a){…}
のどっちが最善かって人によってかなり違うでしょ?
そう言うのを極力やめるって話
あとこういう話になると必ず〇〇はできてねーじゃんとか言うやつが出てくるけど人が使う言語なので理念を優先しすぎて使いにくいものを作ってもしょうがない
そう言うのもちゃんと書いてある
Although practicality beats purity. >>25
そりゃ a という条件の記述でどっちが意図をうまく表現できるかによるでしょ。
unless は if の論理反転だから意味がないとするか、その違いに意味があるとするか
単にボーダーの違いだけと思うがな。
pythonだって
if b >= a and b <= c:
if not (b < a or b > c):
どっちが最善かは意図によって変わるし。 if a <= b <= c:
意図より読みやすいかどうかだな。
最初に思いつきで書いた後に、ドモルガンで書き換えるのはよくやること。 でも海外書籍のイントロでよくあるなぜpythonか?の説明で理由の一つとしてよく挙げられてるのは自然な英語として読めること。
これって日本人にはまったく価値のない宣伝ポイントだよな。 >>11
>There should be one-- and preferably only one --obvious way to do it.
どこに「最善」なんて書いてあるの?
最善の方法というのは比較対象の選択肢を完全に限定した上で
その時点で相対的に最も良さそうだと考えられる選択肢の1つでしかない
置かれた状況や主観だけでなく
スキルレベルやチームメンバーのリテラシーなんかによっても常に変化しうるものなので
ポエムとは言え「最善の方法が1つだけある」なんて書いてたらもっと多くの人にバカにされてる >>26
> unless は if の論理反転だから意味がないとするか、その違いに意味があるとするか
そういう議論になるでしょ
議論になるのは優劣が決め辛いと言うこと
> どっちが最善かは意図によって変わるし。
うん、だからPythonも完璧じゃないよ
そう言う事も書いてあるよね >>30
> だいたいの人が考える最善な方法を1つにするってことね
って書いてあるのに…
だめなケースを挙げられる俺すげー君乙w >>32
obviousを「最善」と誤訳しましたってことでいいのかな?
Although that way may not be obvious at first unless you're Dutch.
オランダ人で無い限り、最初は「最善」な方法には思えないだろうけどw >>29
プログラム言語で使われる程度の英語力ならそんなに苦労しなくて理解できる日本人は多いと思うけどね
まあだからと言って a = b if c else d がすんなり理解できるかと言うと疑問ではあるがw >>33
> obviousを「最善」と誤訳しましたってことでいいのかな?
君がそう思いたいならそれでいいんじゃね?
多分どう説明してもイチャモンつける気満々だしねw >>31
優劣付け辛いというより客観的にどこで線を引くか決めようがない。
だから後付けでpythonのやり方はOKでperlのやり方はNGとしてるだけに過ぎないかもしれないが
それも確かめようもない。 >>36
どこで線を引くかは言語仕様を決める人が決めればいいだけでしょ だからpythonにはpythonの、perlにはperlの基準があって比較のしようもないということ。
pythonの作者が「方法は一つだ」と言えばそうなるわけ。 理念を理解出来ない人っているんだな…
理念自体が間違ってるとか仕様が理念に沿ってないとか言うならまだわかるんだけどね Zen of Python は「単なる理念」でしかないと言っているつもりなんだが?
それ自体正しいとか正しくないとか客観的に判断できるものじゃない。 >>25
> のどっちが最善かって人によってかなり違うでしょ?
人によって違うんじゃなくて、要求によって違う
書き方の違いっていうのは要求の違い
日本人には英語は記号のように見えるが
ネイティブにはこのように見える
・もし A なら実行する
・A でない場合は実行する
これを同じ意味だからってこう書き換えるとわかりづらくなる
Aの反対 でない場合は実行する
もし Aの反対 なら 実行する
ifを使うかunlessを使うかは、どちらが自然な文章になるかであって
「自然な文章」というのが要求
読みやすさという要求によって使う単語を変えるべき Pythonは「方法は一つ」なんて誇大広告を出さずに
ブロックをインデントにすることで、なるべく同じ書き方になるようにした
とか
多くのライブラリを標準で用意することで、オレオレライブラリが量産されるのを防いだ
とか
言うべきだった >>40
うん、君がそう思うならそれでいいんじゃないかな
「単なる理念」なんて無意味だと言うなら君にとってはそうなんだろうし >>41
> 読みやすさという要求によって使う単語を変えるべき
それは君の意見だよね
単語を増やさない方が読みやすいと感じる人もいるから「人によって違う」って書いてあるわけ
理解できるかな? >>42
> Pythonは「方法は一つ」なんて誇大広告を出さずに
>>8に戻るw 特定の問題の明白な解き方が1つだけなんて元々ありえないことなんだから
それを真に受けるやつは流布するやつと同じくらいどうかと思う >>46
要求が同じでも人によって感じ方が異なることなんていくらでもある >>47
目標と実現できてる内容の区別ぐらいしようよ…
実現できてないなら目標なんて無駄と言うならそうなんだろう
お前ん中ではな >>43
お前さんの頭の中じゃ「単なる理念」は無意味なのか。 >>50
どうやったらそんなアホな解釈ができるんだろう…
で、単なる理念でしかないからなんだって言うんだ?
掲げちゃだめなのか? 無意味とか言い出したのは自分だろうに。
「単なる理念」であって「仕様」や「規約」なんかじゃないから、開発者はその理念を汲んで
開発しようとするとしても現実のpythonが必ずしもそうできているというわけではないということ。
加えて言えばそこに明確な基準はないし客観的に判断しようもない。if と unless の話がいい例。 誰が書いても整形ツールを通したような書き方になるのであって
コード(ロジック)が同じようになるわけがない >>55
「python 誰が書いても」でGoogl検索してみました。
ttps://www.google.com/search?client=firefox-b-d&q=python+%E8%AA%B0%E3%81%8C%E6%9B%B8%E3%81%84%E3%81%A6%E3%82%82
ざっど見たところ、「見た目が同じようになる」ではなく「同じようなコードになる」と
書いてあるものが結構ありましたね。
中には、「つまり、誰が書いても似たものになるんです。大事なことなので(ry」と、
念押しして書いているものもありました。
こういう事を平気で書いてあるサイトや書箱があるから、実際に使ってみると
「同じようなコードにはならない」と反論がでるのではないかと思います。 ループをforで書いていたら、Python流は内包表記を使うんだと
書き直させられることがあるからね
どちらかでしかできないことはあるだろうけど、
forを使っても内包表記を使っても出来ることもある。
どちらを使っても出来ることは他にもあるし
人によって書き方は違う >>54
> 無意味とか言い出したのは自分だろうに。
だからどこを見てそんなアホな解釈してるんだよ…
まじで自分の日本語理解力を疑った方がいいぞ
> 加えて言えばそこに明確な基準はないし客観的に判断しようもない。
うん、君の理解力だとそうなんだろうね
それはしょうがないと思うわw >>55-57
〇〇が出来てないとか言う奴がワラワラ出てきて笑うわ ⇒ >>25の後半 Python自体には一貫した理念や哲学なんてないからね
数年以上使ってるやつはみんな知ってる
PHPと一緒でそれが良さでもあるから
宣伝文句を鵜呑みにしてPythonの”理念”を夢見るよりも
現実の問題を解くことに力を注いだほうがいい
Zen of Pythonで言ってることと実際やってることが
違うからっていちいち文句言ってたらキリがないよ >>60
> Python自体には一貫した理念や哲学なんてないからね
うん、君の理解力だとそうなんだろうね
それはしょうがないと思うわw >>61
その証拠にお前だって反論できてないじゃんw >>58
どこを見てもなにも、お前さんの書いた>>43なんだが。
>> 加えて言えばそこに明確な基準はないし客観的に判断しようもない。
>うん、君の理解力だとそうなんだろうね
まさか、明確な基準があって客観的に判断できると言っている? ifとswitchに関しても人によっては違う機能だから
両方用意しろと思うだろうしなぁ
結局Python開発者が考える方針でしかないんだよな >>63
>>43を見て俺が「理念が無意味」と言ってると理解するようなアホには何を説明しても無駄と言う事がよくわかるレスだなw
マジでPythonの理念ガーとか言う前に日本語の勉強し直せよ >>62
なんの根拠も出さずに
> 数年以上使ってるやつはみんな知ってる
とか言い出すやつがそれが証拠とかアホなの?
要するに日本語理解できない奴とか自分の憶測で語る奴にまともな反論なんてできないってだけの話
>>64
> 結局Python開発者が考える方針でしかないんだよな
当たり前だろ、Python以外のプログラム言語の撲滅を企んでるわけでもないのに今更何を言ってるんだよw >>66
「当たり前だろ」のあとの言葉が意味不明だが
「書き方は一つ」というけど、一つじゃないものもあるよね?って他の人が指摘すると
Python開発者は「これとこれは別の機能!だから複数あることにはならない!」って言ってるだけってことだよ
ようするに複数の書き方はあるけど、それを指摘されたら言い訳をしてる。
Python開発者ん中ではこれとこれは別の機能で、あれとあれは同じ機能なんだろうな(笑)っていう話
ifとswitchは別の機能だよ?でもPython開発者ん中では同じ機能なんだろうな
Pythonには便利なシンタックスシュガーは一切搭載しないんだろうな。同じものの別の書き方だからね
https://docs.python.org/ja/3.6/glossary.html
> デコレータの文法はシンタックスシュガーです。次の2つの関数定義は意味的に同じものです:
>
> def f(...):
> ...
> f = staticmethod(f)
>
> @staticmethod
> def f(...):
> ...
クスクス。都合が悪いと別のもの。クスクス なぜ理解できないんだろう…
あとこういう話になると必ず〇〇はできてねーじゃんとか言うやつが出てくるけど人が使う言語なので理念を優先しすぎて使いにくいものを作ってもしょうがない
そう言うのもちゃんと書いてある
Although practicality beats purity. 例えばセキュリティ重視の言語で脆弱性は発生しませんと言語の作者が主張しても
そんなことありえないとわかってるのと同じようなもん
作者がそう主張した所で実現不可能 というか、アホとか日本語ガーとか連呼してる御仁は何を理解してもらいたいんだろう。
Zen of Pythonではああ書いていても現実にはそうじゃない部分もあるという認識は変わらんと思うが。
>>1の「反している」の解釈だけの話なのかな? 全然違うことまで持ち出して何を言いたいんだろう…
脆弱性は発生しませんって売り出してるならJARO案件だしw >>70
> Zen of Pythonではああ書いていても現実にはそうじゃない部分もあるという認識は変わらんと思うが。
同じ内容を何回も言うのはボケの始まりか? ⇒ >>49 >>43無意味とか>>49無駄とか、誰も書いてないことが読めるのは生き辛そうだな。 >>73
日本語の理解力がないって辛いねw
> 「単なる理念」なんて無意味だと言うなら君にとってはそうなんだろうし
これを読んで理念が無意味だと言ってると思うならマジで小学生からやり直した方がいい 相手が言ってもいないことをそう捉えたということだろ。
日本語が日本語がと言っているあんた自身が相当ヤバい。 zen of pythonはジョークを散りばめたポエムなのにユーモアを理解できずに
あれを聖典かのように信奉してる人達がいるんだよ
ある種の宗教だから論理は通じないよ >>75
もしかして仮定法も理解できないとかなの? ポエムでいいならこれで解決じゃん。
zen of pythonはダダ滑りのポエム。
はい解散。 命題
それを否定しうる命題
さらにそれを否定しうる命題
・・・
こういう構成でZen of Pythonは書かれているから
どれか一つに当てはまらないと指摘したところで
別のどれかに必ず当てはまるから”理念”から外れることはない
禅の公案と同じで解釈次第でどうにでも取れるということ
Tim Petersは意図的にやってる >>79
お前がいいならいいんじゃね?
個人的にはポエムとか言い出すなら初めから絡むなよって思うけど ようするにzen of pythonは努力目標
https://www.weblio.jp/content/%E5%8A%AA%E5%8A%9B%E7%9B%AE%E6%A8%99
努力目標 読み方:どりょくもくひょう
目標のうち、達成する可能性は比較的低いものの、達成を目指して努力することを
主な目的として設定された目標のこと。 Guido: The “Zen of Python” is ... Tim Peters wrote it down as a form of poetry.
=> “Zen of Python”はポエム
Guido: Tim has a way with words. “There’s only one way to do it” is actually in most cases a white lie.
=> “There’s only one way to do it”はウソ
「Masterminds of Programming」by Federico Biancuzzi, Shane Warden
https://www.oreilly.com/library/view/masterminds-of-programming/9780596801670/ >>84
もう少しまともな記事を探してくれw
https://impythonist.wordpress.com/2014/02/16/open-heart-with-guido-van-rosuuma-lost-interview-of-python-creator-part2/
IT’S A CATCHY PHRASE.
Guido: Tim has a way with words. “There’s only one way to do it” is actually in most cases a white lie.
There are many ways to do data structures. You can use tuples and lists. In many cases,
it really doesn’t matter that much whether you use a tuple or a list or sometimes a dictionary.
It turns out usually if you look really carefully, one solution is objectively better because
it works just as well in a number of situations, and there’s one or two cases where lists just
works so much better than tuples when you keep growing them.
グイド:ティムは言葉に道があります。「それを行う方法は1つしかありません」は、実際にはほとんどの場合、白い嘘です。
データ構造を行うには多くの方法があります。タプルとリストを使用できます。多くの場合、タプルを使用するか、
リストを使用するか、時には辞書を使用するかは、それほど重要ではありません。よく注意して見ると、
通常は1つの解決策が客観的に優れていることがわかります。これは、多くの状況で同じように機能するためです。
リストを拡大し続けると、リストがタプルよりもはるかにうまく機能するケースが1つまたは2つあります。 >>85
丸パクサイトを持ってきてもう少しまともな記事て言われても
>ティムは言葉に道があります。
はぁ?
>白い嘘です。
はぁ?
もう少しまともな機械翻訳使ってくれw >>86
> もう少しまともな機械翻訳使ってくれw
文句はGoogleにいえ 結局、英語が読めないやつが英語のポエムをポエムと気付かずに盲目に信奉してるだけだったのか
こういうやつを生み出しちゃうのはzen of pythonの弊害だな そのうちお前の孤独死までの介護もAIがするようになるから細かいことは気にするな
アレクサ ポエムを教えて 同じ事するにもメモリガバガバ使って早くしたい時もあるし遅くても仕方ないからメモリ切り詰めたい時もあるじゃない? >>64
switchは2系から必要な人は作ってるから無いものは作るの精神がないとpythonはしんどいだけだろうね > お前は毎朝起きるたびに俺に負けたことを思い出すよ^^
あー、ホンッとに思い出すなあ(笑)
キチガイの嘘つきの低レベルFランの、
朝鮮ゴキブリBot君は、
チョン独特の「なにもできないけど俺のほうがジャップより偉い!」的な
ことはよーくわかったよ。
ホントなにもできない朝鮮ゴキブリBot君!
クソチョンw for num in range(5):
____print(num)
と
num = 0
while (num < 5):
____print(num)
____num += 1 思うにguido的にはmapやfilter特にreduceは要らんが他の若いpython製作者らが要ると言うからしゃーなく搭載しただけだろうなと思う
文字列への変数の展開方法が4種類もあるのはPythonらしくないな
reのcompileも要らんと思うわ普通にraw文字列をre.matchやre.searchの第一引数にすればいいだけ
けどまだ大丈夫
Java辺りのクソ言語に慣れ親しんだ人達が大挙してPythonに侵入してきておかしな事になり始めてるんだろうなとは思うがGuidoが現役の内はまだ安心、引退したらPythonは終わり リスト内包表記の文法はperlみたいな狂気を感じる。
mapやfilterがチェインできたらよかったんだがなぁ。 この板では、単発の質問スレを立てることは禁止です!
速やかに、このスレの削除依頼を出してください