Pythonについて(アンチ専用)

1デフォルトの名無しさん2008/02/21(木) 10:24:06
Pythonが嫌いな人のためのスレッドです。

■関連スレ
Rubyについて(アンチ専用) Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/

844デフォルトの名無しさん2015/01/25(日) 11:35:09.48ID:U0GW9T6b
多分日本語的に読みづらいんだと思うよ。結果が先に来るから。

845デフォルトの名無しさん2015/01/25(日) 11:37:21.13ID:3PovQon7
日本で産まれた(ω) Ruby にも後置 if とかあるのに

846デフォルトの名無しさん2015/01/25(日) 11:44:25.36ID:U0GW9T6b
Ruby は大概書きたい方法があるじゃん

847デフォルトの名無しさん2015/01/31(土) 08:33:30.81ID:xuw3avh8
いくらPythonにへびネタが多いとはいえこういう表紙は駄目だろう
冗談抜きで表紙が気持ち悪くて手に取れないレベル
これが原因でPythonあるいは授業に悪い印象しか残らなかったら学生が可哀想
http://www.skylit.com/mathandpython.html
https://www.packtpub.com/big-data-and-business-intelligence/learning-python-data-analysis

848デフォルトの名無しさん2015/01/31(土) 08:37:29.46ID:YMt5PyZL
カバー付ければ良いだけじゃん
全編写真集なら嫌だけど

849デフォルトの名無しさん2015/01/31(土) 09:24:12.94ID:fHA0y3z4
ジャポニカ学習帳みたいに表紙は植物だけにすればいい
O'Reillyも

850デフォルトの名無しさん2015/01/31(土) 09:34:03.69ID:YMt5PyZL

851デフォルトの名無しさん2015/01/31(土) 10:29:16.24ID:Q5cOubfa
アンチじゃないが表紙ひどいwww

852デフォルトの名無しさん2015/01/31(土) 12:23:49.26ID:Klh2e7Hk
本当だ、何でこんなリアル志向

853デフォルトの名無しさん2015/01/31(土) 12:37:18.71ID:dgL1phRR
>>847
俺は別に平気だけど、もはや何の本か分からんなw

854デフォルトの名無しさん2015/02/04(水) 13:42:49.77ID:5pZRcUKP
>>842
いまどき香具士って・・・

855デフォルトの名無しさん2015/06/28(日) 15:54:47.88ID:XDTH7fdP
Pythonって単純な後置ifが使えないみたいだけど
それだとそのためだけにif文でインデントがひとつ深くなって
インデントが重要な言語仕様にとっては欠陥なんじやないかな
import thisでもネストしてるよりフラットがいいって言ってるんだし

856デフォルトの名無しさん2015/06/28(日) 20:53:17.33ID:92vB0cyt
hoge = a if b else c

857デフォルトの名無しさん2015/06/28(日) 21:07:18.70ID:lxz6gjyn
Python使ってもクソコード書く奴はクソコードを書く。
言語変えたからって良いコードにはならない。

858デフォルトの名無しさん2015/06/28(日) 21:07:55.71ID:lxz6gjyn
hoge = a if b else c
hoge = b ? a : c

後者のほうが短くて可読性が高い。

859デフォルトの名無しさん2015/06/28(日) 21:19:54.87ID:I6pGNCnf
elseが必要な場合ばかりじゃないじゃないですか
単純な後置ifって書いたのはそういう意味です
単純な条件判定だけすれば十分っていう場合
その「単純な〜だけすれば十分」っていうのと
仕様上不可欠なインデントを要求するのがバランスとれてない感じがするんですよね
まあ単純にインデント増えるとコードがわかりにくくなるなるっていうのが
文句言ってる理由なんですけど

860デフォルトの名無しさん2015/06/28(日) 21:24:02.23ID:lxz6gjyn
Pythonのインデントでブロックを表現するというのは
面白いが、メリットはない。

861デフォルトの名無しさん2015/06/28(日) 21:25:10.72ID:I6pGNCnf
いや逆だな
コードの分かりにくさなんていろんな理由で発生するからこの件だけ文句言う理由がない
「単純な〜だけすれば十分」っていうのと
仕様上不可欠なインデントを要求するのがバランスとれてない感じがする
っていうのが文句言いたくなった本当の理由です
なんとなくすっきりしないという

862デフォルトの名無しさん2015/06/28(日) 21:27:03.42ID:lxz6gjyn
インデントでブロックを表現するというのは
デメリットも有る。

例えばデバッグプリントするとき、他の言語なら、わざとインデントを外して
目立つようにできるが、Pythonだといちいち揃えないといけない。
消す時面倒くさい。

また試しに他の部分からコードを持ってきたり、
コードの順番を入れ替えてみたりする時、
ちゃんと揃えないと動かない。

仮のコードが書きにくい。

863デフォルトの名無しさん2015/06/28(日) 22:07:47.22ID:92vB0cyt
>elseが必要な場合ばかりじゃないじゃないですか

大抵のケースでは
hoge = c
hoge = a if b

hoge = a if b else c


あるいは
hoge = a if b else None

864デフォルトの名無しさん2015/11/07(土) 17:03:07.54ID:rKOE1Rwz
あほちゃう

865デフォルトの名無しさん2015/11/07(土) 20:16:30.77ID:J5i3UOGI
あほちゃう

866デフォルトの名無しさん2015/11/08(日) 15:23:00.76ID:QYMRsb+2
どうでもいいことで文句言ってるだけにしか思えん。

867デフォルトの名無しさん2015/12/04(金) 13:08:41.19ID:cIAl+Zzr
re内でしか正規表現使えないの不便すぎ

868デフォルトの名無しさん2015/12/04(金) 15:10:18.61ID:prxSfFNA
そうでもない

869デフォルトの名無しさん2015/12/15(火) 09:34:12.26ID:GmzcEDm2
D の std.regex に似てる

870デフォルトの名無しさん2016/08/07(日) 16:59:44.06ID:nuDQx96v
そうでもな

871デフォルトの名無しさん2016/08/08(月) 00:00:14.29ID:xVTmsFhH
インデントするかしないかなんて書き手に任せればいいじゃん。
構造が分かっているなら自動整形のツールだって作れるわけだし。

なんかそんなところまで縛って、基本的なところでインデントが
プログラムの文法に縛りを与えるってなんか嫌な設計だよね。

872デフォルトの名無しさん2016/08/08(月) 17:57:42.17ID:1QM6yHGZ
前はそう思ってたけど
実際書いてみると
問題になるケースはほとんどないよ
君も外からgdgd言ってないで書いてみろ

873デフォルトの名無しさん2016/11/09(水) 19:52:52.94ID:em+Lyjx7
あー、でも切り貼りしずらいというのはあるね
ある部分だけ外に出したいとか、逆に括りたいときに、ちょっと手間
インデントが一意に定まらないから、オートインデントしずらいんだよね

874デフォルトの名無しさん2016/11/09(水) 23:10:35.98ID:gLDp2Y3W
>>873
ブロック単位でインデントの深さは切り離せるから違ってても良いんだわ

つまり
「ある部分だけ切り離す」
っていうのは全然問題にならない

875デフォルトの名無しさん2016/11/09(水) 23:11:57.92ID:gLDp2Y3W
>逆に括りたいとき

この場合は
if True:
って書いてしまえばほとんどのケースで解決する

876デフォルトの名無しさん2016/12/21(水) 20:50:38.88ID:RJ5TtbA5
Pyconのあのおっさんいい加減うざい

877デフォルトの名無しさん2016/12/22(木) 00:35:33.27ID:J1Y5kwjp
うむ

878デフォルトの名無しさん2017/08/25(金) 15:07:32.02ID:0nrK3Ckt

879デフォルトの名無しさん2018/05/23(水) 21:51:31.70ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

2UWPR

880デフォルトの名無しさん2018/07/05(木) 00:10:36.37ID:RfoszcD2
077

881デフォルトの名無しさん2018/08/31(金) 17:46:44.07ID:/xTCWZjj
今後 Python使える人増えるでー
学校教育用言語に選ばれたからね
ヨーロッパではPythonが大注目
米国も追従するかは不明
日本は応用が利かないフローチャート風
なんで、日本はいつも行き止まりな道しか選ばないのか
仮想アセンブラのCASLなんて何の役にもたたなかったし
外国の小学生と日本の小学生の格差は広がるばかり

882デフォルトの名無しさん2018/08/31(金) 18:02:23.50ID:958KuBfY
python使うのはありだけど
日本の学校で教えると
pythonしか使えない人とかも出てきそう
大事なのはそこじゃなくて
アルゴリズムとかなんだけど
どんな言語でも書ける能力を磨くとかそういう発想はなさそう

883デフォルトの名無しさん2018/08/31(金) 19:05:06.17ID:9BvJl+C0
>>882
そんなもんおまえが気づけた程度の極意なんやから
未来ある有望な子どもたちは当たり前のように気づくやろw
論理的ってこうゆう事やでアホンダラw

884デフォルトの名無しさん2018/08/31(金) 23:27:44.03ID:N52+Kto5
日本の学校は子供を潰す
延びる芽を摘む教育

885デフォルトの名無しさん2018/09/01(土) 00:19:19.24ID:MpWrJr2V
>>884
言っとくけどおまえの芽はもとから腐っとったからなw

886デフォルトの名無しさん2018/09/01(土) 16:47:17.22ID:h137Mfrw
インデントが崩れちゃうとそれだけで構造が読みにくくなる。
整形もプログラムを読解しながらやらなきゃならないので非常に効率が悪い。

887デフォルトの名無しさん2018/09/08(土) 13:20:48.49ID:3pEPHB8S
>>884
子供は教師のマウンティングするための道具でしかないからな。

888デフォルトの名無しさん2018/09/15(土) 15:16:31.17ID:heijdb7v
Pythonって、リストに値を追加する時、配列のような index 番号か、
または、'Hello' などの値を指定して、その値を探して一致した要素
の直前か直後辺りに追加する事は出来ても、C言語のように、
ポインタを指定して、そのポインタの指す要素の直後に追加する
ことは出来ないよね。

もし、そうだとすると、言語自体が高速動作に向いてない。

元々、データ構造的にリストとは配列とは異なる概念で、前者は
ポインタで互いに要素をリンクした構造。

だから、index 値から、要素を特定するには、先頭から順番に
「辿る」作業が必要で、要素数がNの時、O(N)の時間がかかって
しまう。値を探すのも、当然O(N)の時間がかかる。

Cの場合のポインタや参照などで場所を指し示す方法だけが、
O(1)の時間で済む。

ポインタの概念が理解しにくい人もいるらしいが、Pythonの方法だと、
どんなにCythonなどでコンパイルしても、アルゴリズム的に
速度は上がらない。

889デフォルトの名無しさん2018/09/15(土) 15:32:30.08ID:heijdb7v
以下の仕様もダメ。ループでの要素削除がまともに出来ない。この不具合
を回避するためにはリストをまるまるコピーしなくてはならず、とても効率が悪い。
Cythonでコンパイルしても、Cに比べてとても遅くなってしまう。


http://blog.livedoor.jp/kmiwa_project/archives/1030391127.html
http://sakitake.blogspot.com/2012/10/pythonfor.html

Python で リストの中身をforループで削除する時の注意点。

numbers = [1,2,3,4,5]

とあって、for ループで numbers の中身を消したいと思って、下記のようにすると、失敗する。

for e in numbers:
  numbers.remove(e)

numbers の中に、 2と4 が残ったままとなる。

numbers = [2,4]

Pythonの仕様。

そこで、このようにする。

for e in numbers[:]:
  numbers.remove(e)


[:] とすることで元のリストのコピーとなり要素の順番を全て取得でき、全ての要素を順番に削除が行える。

890デフォルトの名無しさん2018/09/15(土) 15:54:07.45ID:heijdb7v
>>888
「辞書」や「集合(Set)」は、O(1)で探せるらしいが、それは、Hush法を用いている
からだ。しかし、例え O(1)でも、データを探すには、例えばデータが文字列なら
最低1回の文字列比較(C言語でのstrcmp()みたいなもの)は必要になるので、
文字の長さに比例した時間がかかってしまう。

要素(データ)が文字列の場合に限らず、1つ1つの要素のデータが複雑
になった場合は、その複雑さに比例したような検索時間がかかるようになる。

つまり、要素数をN、1つあたりの要素の平均サイズをM とすると、
「辞書」や「集合」であっても、O(M)の時間がかかる。

リストなら、O(M・N)の時間がかかる。

一方、C言語のリストなら、ある要素の直前、直後に追加するのには、
全く探す動作が必要ないので、O(1)で済む。

こういうところが、PythonとCの速度差に繋がる。

891デフォルトの名無しさん2018/09/15(土) 15:59:11.04ID:AVfR6YnT
>>888
numpy

892デフォルトの名無しさん2018/09/15(土) 17:45:41.50ID:iqED3/RG
【IT】奴隷制を連想させるとして、Pythonで「master」「slave」といった単語が削除される
https://egg.2ch.net/test/read.cgi/bizplus/1536925223/

893デフォルトの名無しさん2018/09/16(日) 02:05:46.60ID:UmczuJY3
>>892
バカだよな。
つっぱねるべきだった。

894デフォルトの名無しさん2018/09/16(日) 11:17:08.95ID:HF0YmRsW
povertyかと思った

新着レスの表示
レスを投稿する