Pythonについて(アンチ専用)
レス数が900を超えています。1000を超えると表示できなくなるよ。
Pythonが嫌いな人のためのスレッドです。
■関連スレ
Rubyについて(アンチ専用) Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/ >>810
インデントの深さを表示できるエディタを使うとか
いくらでもやりようはあるでしょ python初心者だけど面白いよ面白い!でもpythonerが排他的っぽい;; 代入演算子が値ではなくてリファレンスの代入という仕様はハマるな。
みんな慣れてるの?
他の言語と基本的なことが違い過ぎる。 Pythonは他の言語からの人がはまる仕様が結構ある。
デフォルト引数が評価されるタイミングとか。
FAQに纏まってるので、早めに目を通すといいよ オブジェクトを指す変数がリファレンスだなんて、ほとんどの言語であたりまえだわ。
むしろポインタを生で扱わないといけないので、明示的にデリファレンスをしないと
いけない、CとC++のほうが例外的。
PHPは、何も考えてない言語仕様だから変なことになってるけど、まぁPHPだからw >代入演算子が値ではなくてリファレンスの代入という仕様はハマるな。
これは、割とどの言語でも繰り返されてきた話題なんだけど、
言語間での"リファレンス/参照"という語句の、食い違いによる説明の混乱というものがあって
C++で言う(alias的な機能の)"リファレンス/参照"は、Pythonにはなく、
C/C++の語句で言うなら、Pythonでのオブジェクトのリファレンスとは、
単に"オブジェクトの構造体を指すポインタの値"。 Aという言語を使ってきた人がBという言語を使い始めた時にハマるポイント、
なんてのは、どんな組み合わせでもまず間違いなく絶対あるよな。 インデントの使用で読みやすいとは言うが、糖衣構文やデコレータバンバンだから
実際の現場で使われているアプリのレベルのソースはちょっと分かりにくい
よくある話だが、教育用と実用性を両立させようとするとどうしてもこうなる デコレータで読みにくくなるなんて
そりゃ知能が絶望的に足りてないんだよ デコレータ使わず、糖衣構文を展開した形で書かれていれば理解できるんだい、
(と信じようとしている)。 日本ではPythonはもう終わりだ...
発展はない
始めるのはゆとりばかり
質問なんかも酷いもんだ
PHPより遥かに劣る osとshutilに分かれてる意味がわからない。
日付が使いにくい。
lenがオブジェクトのメンバに無いのがおかしい。
absがmathじゃないのはおかしい。
はじめたばかりだけど、ざっと見てなんかライブラリがとっ散らかってる印象。 気になるのは最初だけだから
通過してしまえば一瞬で忘れられる
そんな小さいことにいつまでも構ってられるほど python の世界は狭くはない
安心して使い続けるがよい ライブラリがとっ散らかってると、マニュアル引くとき困るんだが。
このくそライブラリのせいで学習曲線絶対急になってるよね。イラつくわ。 sysとosとか、きちんと意味があって分けられているけどな。
なんでもグローバル名前空間にぶち込んであるのが好きならPHP使ってろよw > lenがオブジェクトのメンバに無いのがおかしい。
__len__メソッドが代わりにあるから使えよ。
ちなみにlen関数がやってくれてる型チェックも自前でやれよ。 型チェック?なぜそんなことをしなければいけないのか 流石 __len__ すら知らずにアンチを気取るマヌケは言うことが違うなw Pythonってリスト内包表記が中途半端で使いにくい。
array = [1, 2, 3, 4, 5]
[x*2 for x in array if x<3]
これはmap とfilterの組み合わせで、プログラミング言語として考えたらこんな複雑な構文は面倒くさいだけだし、
x*2 for x の部分をlambdaだと考えたら仮引数が後ろに来ていて非常に読みにくい。
matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
[[c*2 for c in r] for r in matrix]
数式に近い書き方なんだと考えたら考えたで、行列のような多次元データ構造を扱うには
内包表記をネストしないといけなくなって複雑になる。結局何をやるにしてもnumpy頼みになる。 Pythonの内包表記が中途半端ってどういうこと?
Haskellの内包表記も似たようなもんだよ
それに慣れると(Haskellにおいてすら)mapやfilterより読みやすい
[x * 2 | x <- array, x < 3]
map (* 2) $ filter (< 3) $ array >x*2 for x の部分をlambdaだと考えたら仮引数が後ろに来ていて非常に読みにくい。
そんな香具師いるんかね
むしろ
[2*x for x in array if x<3]
とかのとき
[('%s'*x) for x in array if x<3]
と解釈されるはずだと思うところが
ひょっとすると
['%s'%(x for x in array if x<3)]
の可能性も捨てきれないと思ってしまう なんか切り貼りしてたらおかしくなったので訂正
むしろ
['%s'%x for x in array if x<3]
とかのとき
[('%s'%x) for x in array if x<3]
と解釈されるはずだと思うところが
ひょっとすると
['%s'%(x for x in array if x<3)]
の可能性も捨てきれないと思ってしまう >>838
数式に親しくないプログラマにとっては「今のところ」後者のmapとfilterで平凡に書く方が分かりやすいと思うけどな。
Haskellでは後者の書き方でも色々と非凡になるけどw
(今のところってのは、昔はそもそも無名関数自体一般的じゃなくてループの方が分かりやすい時代だった。
今は無名関数くらい誰でも使う。何が分かりやすいかも時代で変わってくるから、時代に合わせたプログラミング大事)
本題。中途半端って言ったのは、そこじゃなくて。
今、内包表記を苦もなくスラスラ読めるプログラマってどんな奴だ?
→数式を読めるプログラマだろ
→数式を読めるプログラマはどんなプログラムを書く?
→数学の問題を解くプログラムだろ
→数学の問題をプログラミングするなら、行列の各要素を二倍するなんてこう書きたいだろ(Rのように)
matrix*2 >数式に親しくないプログラマ
そんな香具師いるんかね >>841
>→数学の問題をプログラミングするなら、行列の各要素を二倍するなんてこう書きたいだろ(Rのように)
>matrix*2
それこそ numpy でいいやん 多分日本語的に読みづらいんだと思うよ。結果が先に来るから。 日本で産まれた(ω) Ruby にも後置 if とかあるのに カバー付ければ良いだけじゃん
全編写真集なら嫌だけど ジャポニカ学習帳みたいに表紙は植物だけにすればいい
O'Reillyも >>847
俺は別に平気だけど、もはや何の本か分からんなw Pythonって単純な後置ifが使えないみたいだけど
それだとそのためだけにif文でインデントがひとつ深くなって
インデントが重要な言語仕様にとっては欠陥なんじやないかな
import thisでもネストしてるよりフラットがいいって言ってるんだし Python使ってもクソコード書く奴はクソコードを書く。
言語変えたからって良いコードにはならない。 hoge = a if b else c
hoge = b ? a : c
後者のほうが短くて可読性が高い。 elseが必要な場合ばかりじゃないじゃないですか
単純な後置ifって書いたのはそういう意味です
単純な条件判定だけすれば十分っていう場合
その「単純な〜だけすれば十分」っていうのと
仕様上不可欠なインデントを要求するのがバランスとれてない感じがするんですよね
まあ単純にインデント増えるとコードがわかりにくくなるなるっていうのが
文句言ってる理由なんですけど Pythonのインデントでブロックを表現するというのは
面白いが、メリットはない。 いや逆だな
コードの分かりにくさなんていろんな理由で発生するからこの件だけ文句言う理由がない
「単純な〜だけすれば十分」っていうのと
仕様上不可欠なインデントを要求するのがバランスとれてない感じがする
っていうのが文句言いたくなった本当の理由です
なんとなくすっきりしないという インデントでブロックを表現するというのは
デメリットも有る。
例えばデバッグプリントするとき、他の言語なら、わざとインデントを外して
目立つようにできるが、Pythonだといちいち揃えないといけない。
消す時面倒くさい。
また試しに他の部分からコードを持ってきたり、
コードの順番を入れ替えてみたりする時、
ちゃんと揃えないと動かない。
仮のコードが書きにくい。 >elseが必要な場合ばかりじゃないじゃないですか
大抵のケースでは
hoge = c
hoge = a if b
が
hoge = a if b else c
だ
あるいは
hoge = a if b else None インデントするかしないかなんて書き手に任せればいいじゃん。
構造が分かっているなら自動整形のツールだって作れるわけだし。
なんかそんなところまで縛って、基本的なところでインデントが
プログラムの文法に縛りを与えるってなんか嫌な設計だよね。 前はそう思ってたけど
実際書いてみると
問題になるケースはほとんどないよ
君も外からgdgd言ってないで書いてみろ あー、でも切り貼りしずらいというのはあるね
ある部分だけ外に出したいとか、逆に括りたいときに、ちょっと手間
インデントが一意に定まらないから、オートインデントしずらいんだよね >>873
ブロック単位でインデントの深さは切り離せるから違ってても良いんだわ
つまり
「ある部分だけ切り離す」
っていうのは全然問題にならない >逆に括りたいとき
この場合は
if True:
って書いてしまえばほとんどのケースで解決する 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
2UWPR 今後 Python使える人増えるでー
学校教育用言語に選ばれたからね
ヨーロッパではPythonが大注目
米国も追従するかは不明
日本は応用が利かないフローチャート風
なんで、日本はいつも行き止まりな道しか選ばないのか
仮想アセンブラのCASLなんて何の役にもたたなかったし
外国の小学生と日本の小学生の格差は広がるばかり python使うのはありだけど
日本の学校で教えると
pythonしか使えない人とかも出てきそう
大事なのはそこじゃなくて
アルゴリズムとかなんだけど
どんな言語でも書ける能力を磨くとかそういう発想はなさそう >>882
そんなもんおまえが気づけた程度の極意なんやから
未来ある有望な子どもたちは当たり前のように気づくやろw
論理的ってこうゆう事やでアホンダラw >>884
言っとくけどおまえの芽はもとから腐っとったからなw インデントが崩れちゃうとそれだけで構造が読みにくくなる。
整形もプログラムを読解しながらやらなきゃならないので非常に効率が悪い。 >>884
子供は教師のマウンティングするための道具でしかないからな。 Pythonって、リストに値を追加する時、配列のような index 番号か、
または、'Hello' などの値を指定して、その値を探して一致した要素
の直前か直後辺りに追加する事は出来ても、C言語のように、
ポインタを指定して、そのポインタの指す要素の直後に追加する
ことは出来ないよね。
もし、そうだとすると、言語自体が高速動作に向いてない。
元々、データ構造的にリストとは配列とは異なる概念で、前者は
ポインタで互いに要素をリンクした構造。
だから、index 値から、要素を特定するには、先頭から順番に
「辿る」作業が必要で、要素数がNの時、O(N)の時間がかかって
しまう。値を探すのも、当然O(N)の時間がかかる。
Cの場合のポインタや参照などで場所を指し示す方法だけが、
O(1)の時間で済む。
ポインタの概念が理解しにくい人もいるらしいが、Pythonの方法だと、
どんなにCythonなどでコンパイルしても、アルゴリズム的に
速度は上がらない。 以下の仕様もダメ。ループでの要素削除がまともに出来ない。この不具合
を回避するためにはリストをまるまるコピーしなくてはならず、とても効率が悪い。
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)
[:] とすることで元のリストのコピーとなり要素の順番を全て取得でき、全ての要素を順番に削除が行える。 >>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の速度差に繋がる。 >>889
配列からの削除なんて、要素がずれるから、全言語でバグる >>> a = [1, 2, 3, 4, 5]
>>> for e in range(len(a)): a.pop()
>>> a
[] >>888
PythonのリストのランダムアクセスはO(1)で、実態は配列だよ
また、Cのポインタは配列アクセスと同じなので、
配列操作に関して言えばポインタを持つのもインデックスを持つのも同じ
int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
b = 2;
// a[b] == *(a + b) == *(b + a) == b[a] == 2 誰が書いても同じように書けるとか言うくせに
同じようなモジュールたくさん作りやがって。
ディレクトリ名取るのに os.listdir と glob.glob と pathlib.glob ... バカかよ。 C:/Users/Owner/Documents/*.txt
Ruby では、Windows のファイルパスを、/ で書けるけど、
Python では、\ だから、うっとおしい! うちのpythonはwindowsでも/使えてるんだが python のことを何も知らないで荒らしてるルーピーなんかホットケーキ map あるのに list内包とか作ってブレブレ。
list 返すのか iterable オブジェクト返すのかも。
オブジェクト指向に関数型の見た目だけ取り入れてごちゃごちゃ。
初心者の取り込みには成功したね。
上級者の生産性は落ちるけど。 確かにpy3になってlist(hoge)することが多くなった
もう少し柔軟に暗黙の変換してくれてもいいのに Pythonはスリザリンの陰謀だからな
つまりそれはあの人を彷彿とさせるのであって邪悪なんだよ >>910
>自分が知っている範囲では、他のメジャーな言語でこれほどコロンを多用する言語はない。
BASIC でマルチステートメント使わないのかな? 私は馬鹿ですって言ってるようなもの
●コロン忘れる←セミコロン行末に書く言語のことを忘れてるだけじゃね
●Scheme/Rubyと比べて値返し←Cも知らんのかこいつ&PythonはPerlの悪弊から逃れられたのにRubyの悪弊持ち込んでどうする? >自分が知っている範囲では、他のメジャーな言語でこれほどコロンを多用する言語はない。
せやな… C++
> Pythonでは、関数が返す値には明示的に「return」を付ける必要があるのだ。
せやな… PowerShell レス数が900を超えています。1000を超えると表示できなくなるよ。