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

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

8 :デフォルトの名無しさん:2008/02/21(木) 15:22:37
Pythonもアンチスレできたのかwww

13 :デフォルトの名無しさん:2008/02/22(金) 00:52:21
あーそれは思った。len(hoge)ってvbsかよwって。
for i in range(1, len(hoge) - 1) :とかも萎えたな。

38 :デフォルトの名無しさん:2008/02/23(土) 21:44:51
IronPythonのipc.pyでコンパイルされたexeが激遅で萎えた

44 :デフォルトの名無しさん:2008/02/24(日) 09:47:35
なので、オライリーの本が買えない

65 :デフォルトの名無しさん:2008/02/24(日) 23:25:43
空白いれたくなければ、
print("%s%s%s" % (hoge, 4,5.67)
とすりゃいいんじゃないの。
改行いれたくなければ標準出力様にお願いしなさい:-)

77 :デフォルトの名無しさん:2008/02/25(月) 22:38:07
>>65
>print("%s%s%s" % (hoge, 4,5.67)
こんなコードを何の疑問にも思わないお前のオツムがあっぱれ

99 :デフォルトの名無しさん:2008/02/26(火) 21:46:47
と、こくごに四苦八苦なゆとりが申しております。

131 :デフォルトの名無しさん:2008/03/01(土) 04:40:26
UTF-8で保存されているファイルをEUCに変換したくて次のような症状が出ています
元ファイルに含まれている「??」という文字のところで止まってしまうようです
(この文字がなければ正常に変換出来ました)

最初はこちらを試しました
?? ifp = open(src, 'rb')
?? ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
?? ofp.write(ifp.read().decode('utf-8'))

UnicodeEncodeError: 'euc_jp' codec can't encode character u'\u9ad9' in position
163: illegal multibyte sequence

その後こちらも試しましたが却って訳が分からなくなりました
?? ifp = codecs.getreader('utf-8')(open(src, 'rb'))
?? ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
?? ofp.write(ifp.read().decode('utf-8'))

UnicodeEncodeError: 'ascii' codec can't encode character u'\u9ad9' in position 1
63: ordinal not in range(128)

どう書けば正しく変換出来るのでしょうか?

136 :デフォルトの名無しさん:2008/03/01(土) 09:54:38
>>131
UTF-8では表せるけどEUC-JPでは表せない文字というのが山ほどあって
はしごだかはそのひとつ。完全には変換できないです。

読み書きしているファイルが実は??HTML??や??XML??だとしたら
xmlcharrefreplace??エラーハンドラが便利かも。

>>>??import??codecs
>>>??ifp??=??codecs.open("input.txt",??"r",??encoding="utf-8")
>>>??ofp??=??codecs.open("output.txt",??"w",??encoding="euc-jp",??errors="xmlcharrefreplace")
>>>??ofp.write(ifp.read())
>>>??ifp.close()
>>>??ofp.close()

137 :デフォルトの名無しさん:2008/03/01(土) 16:07:09
>>136
ビンゴです
ありがとうございました

しかし「??」はEUCにもあるのに「??」になってしまう副作用が出ますね・・・

209 :208の続き:2008/06/07(土) 13:24:23
じゃあ具体的にどうすればいいのかという話だけど、お勧めは次の方法だ。
まず次のように標準出力を適当なエンコーダで包む。

import??codecs
Writer??=??codecs.getwriter(sys.getfilesystemencoding())
stdout??=??Writer(sys.stdout)

その上で??print??文をすべて次のように書く。

print??>>stdout,??'"total","%s",%d'??%??(root,??dirsize[root])

この例ではリダイレクトしているか否かに関わらず??sys.getfilesystemencoding()??の返す
エンコーディングでエンコードするようにしている。このエンコーディングは、俺の知る限り
標準出力がリダイレクトされていない場合の??sys.stdout.encoding??と一致している。
sys.getfilesystemencoding()??を使う代わりに、例えば??cp932??に決めうちしちゃうとか、
コマンドライン引数で出力エンコーディングを指定するようにするといった方法も考えられる。
標準出力リダイレクト時のエンコーディングをどうするかは用途に強く依存する問題なので
こればかりはプログラムを書く人(つまり197さん)が決めるしかない。

210 :デフォルトの名無しさん:2008/06/07(土) 14:04:17
>>209
u'"total","%s",%d'じゃない?

218 :デフォルトの名無しさん:2008/06/08(日) 00:03:06
二進数表記が欲しいなーと思ったことはあったような無かったような

420 :デフォルトの名無しさん:2009/05/28(木) 19:01:04
pythonはforが大杉。

424 :デフォルトの名無しさん:2009/06/08(月) 11:45:51
>>420
for で充分だから ブロック構文いらない。

Ruby厨はよく Pythonには○○が無いって叩くけど、大抵そういう機能は
Python-Idea ML で必要・不要が議論された結果不要と判断されている
ので、その機能が無くても同じ生産性をPythonは既に実現している。

426 :デフォルトの名無しさん:2009/06/08(月) 20:46:12
>>424
そうでもないだろ。

Pythonの配列操作がRubyと比べて面倒くさい
ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

それよりPythonはsuperのキモさをなんとかしてくれんかいのう。
なんでsuper()に親クラス名を指定しなきゃいかんの?ba

431 :デフォルトの名無しさん:2009/06/08(月) 21:13:13
>>426
> なんでsuper()に親クラス名を指定しなきゃいかんの?ba

Smalltalk系のようにsuperがcaller側のmethodのbindに依存するほうが
よほど言語設計として汚ないと思うが?

433 :デフォルトの名無しさん:2009/06/08(月) 22:15:57
明示的なだけで汚くはないだろ
多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
Python3からは引数省略してsuper().methできるらしいけど

440 :デフォルトの名無しさん:2009/06/09(火) 03:20:53
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788
メソッドチェーンになれたRubyistがメソッドチェーンを無いことを反射的に
批判しているだけだろ。

文を分けないで関数を無制限にゴチャゴチャ繋げるのはPythonicではない。
一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
文を分けるべき。文を分けたることによって数タイプ増えるが、その分可視性は
向上するので、トータルの生産性に大きな差は無い。それなら、すっきりした
書き方だけを使うのが Pythonic way.

445 :デフォルトの名無しさん:2009/06/09(火) 05:13:49
>なんか今更この記事にコメントが付きだしたのですが、どこかで紹介されたのでしょうか?
笑える

>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

ruby
a.sort().reverse().map{|x| x.to_s}.join('-')

python
'-'.join(map(lambda x:str(x), reversed(sorted(a))))
'-'.join(str(x) for x in reveresed(sorted(a)))
'-'.join('%s'%(x) for x in sorted(a, reverse=True))

確かpythonって「やりかたはひとつ」を売りにしてなかったっけ?

448 :デフォルトの名無しさん:2009/06/09(火) 08:14:19
>>445
>python
>'-'.join(map(lambda x:str(x), reversed(sorted(a))))
>'-'.join(str(x) for x in reveresed(sorted(a)))
>'-'.join('%s'%(x) for x in sorted(a, reverse=True))
>
>確かpythonって「やりかたはひとつ」を売りにしてなかったっけ?

厳密にひとつ、というわけじゃなくて、だいたい一つ、ぐらいの意味でいいんじゃない?
これくらいだったら十分許容範囲だろ。許してやれよ。


> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')

これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
Python狂信者はこの事実を認めようとしないだろうけど。

>>440
>一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
>文を分けるべき。
それはPython限定の話だよね? 一息に書きにくい言語はそうすべきだけど、
一息にかける言語だったらそんなことに縛られる必要はまるでない。

>> 443
> 単に初学者が前に習った言語の作法にひきずられて
> 今学んでいる言語の流儀に逆らってるだけに見える。
こういうやつがいるかぎりは、争いはいつまでたっても終わんないだろうね。

452 :デフォルトの名無しさん:2009/06/09(火) 09:15:13
>>445
その例だと、一番目は lambda が不要で
'-'.join(map(str, sorted(a, reverse=True))) # もしくは itertools.imap

二番目は reversed が一つ余計で
'-'.join(str(x) for x in sorted(a, reverse=True))

三番目の % 記法を無理やり使うのは無いな。少なくとも (x,) としないと、 x 自体がタプル
だったときに問題が起こる。

454 :デフォルトの名無しさん:2009/06/09(火) 09:24:33
>>448
> > ruby
> > a.sort().reverse().map{|x| x.to_s}.join('-')
>
> これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
> Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
> Python狂信者はこの事実を認めようとしないだろうけど。

「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」
左から右なんだよね。なんで代入は右から左のままなの?代入演算子を => に
すれば、
s = a.sort.reverse
s.map{|x| x.to_s}.join('-')
という風に代入が混じっていても、
a.sort.reverse=>s.map{|x| x.to_s}.join('-')
って書けるのにさ。
結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
とか言っちゃってる気がしてならない。

あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
どうなんだ? Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという
方が分かり易いし正しいと思うぞ。

464 :デフォルトの名無しさん:2009/06/09(火) 14:43:05
>>454
>「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」左から右なんだよね。
なんですべてを左から右にしようとしてんの?別に右から左でもいいけどさ、個々の処理がきれいに流れていることが重要なんじゃん。
unixのコマンドラインでパイプを使って処理を連結する感覚と一緒。Pythonとかだとそれがないってだけ。

>なんで代入は右から左のままなの?代入演算子を => にすれば、
>s = a.sort.reverse
>s.map{|x| x.to_s}.join('-')
>という風に代入が混じっていても、
>a.sort.reverse=>s.map{|x| x.to_s}.join('-')
>って書けるのにさ。
そんなふうに書くわけないじゃん。
(s = a.sort.reverse).map{|x| x.to_s}.join('-')
でいいだろ。自分で書いてて気づかないのか?

>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。
いや実際読みやすいだろ。

>あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのはどうなんだ?
連結した結果として文字列以外になんかあるか?joinは*要素を連結して*文字列として返すメソッドなんだから、リストのメソッドで何にもおかしくない。

> Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという方が分かり易いし正しいと思うぞ。
戻り値が文字列だからといって、要素を連結する機能を文字列に関する機能と考えるほうがどうかしてる。
joinはあくまで「要素を連結する」ためのメソッド。リストのメソッドで何が悪い。

>>452
おれもlambda x: str(x) とか書いてた!これはいらないのか!ちょー参考になった。さんくす。


469 :デフォルトの名無しさん:2009/06/09(火) 14:51:33
>>464
例えば、xhtml を動的に生成する場合、
data = [tag.P(t) for t in "foo bar baz".split()]
contents = tag.HR.join(data)
print str(contents)
で、
<p>foo</p>
<hr/>
<p>bar</p>
<hr/>
<p>baz</p>
とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
文字列処理にしか出てこないとは限らないだろ。

477 :デフォルトの名無しさん:2009/06/09(火) 15:29:55
Pythonのjoinが文字列のメソッドとなっているのは、単にリストだけでなくタプルや文字列やジェネレータのように
繰り返し可能なものすべてを扱えるようにしているからだよね。

だからほんとは
join(iteratable, separator='')
という関数でよかったんじゃないの?
joinが文字列のメソッドだからすごく違和感があるけど、単なる組み込み関数として存在するなら、別に違和感なし。

join(['a', 'b', 'c'])
join(('a', 'b', 'c'))
join(x for x in 'abc')


481 :デフォルトの名無しさん:2009/06/09(火) 16:08:40
>>469
>シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
>文字列処理にしか出てこないとは限らないだろ。
だったらなおさら文字列のメソッドにするべきじゃないだろ。
セパレータは文字列と限んないんだろ?joinを文字列のメソッドにしたら、セパレータは文字列限定じゃないか。
join(seq, sep='') のような組み込み関数にしとくべきだろ。
''.join()が文字列しか対象としてないのを忘れて「文字列処理にしか出てこないとは限らない」とかバカじゃねーの


490 :デフォルトの名無しさん:2009/06/09(火) 22:26:46
>>469
Python標準では str 以外で join() を実装しているのってあるの?
hogehoge.join(['a','b','c']) # hogehoge は何か
文字列以外の join() が用意されてないなら、469のは説得力を感じないなあ。

491 :デフォルトの名無しさん:2009/06/09(火) 22:58:11
>>490
少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
名前はスレッドの join であったり db の join であったりたくさんあるよ。

逆に、 str.join だと何か問題があるの?グローバルという特別な空間を
犯したり、リスト・タプル・その他すべてのイテレート可能型の名前空間に
文字列のための "join" メソッドをねじ込まないといけない理由は何?

492 :デフォルトの名無しさん:2009/06/09(火) 23:51:10
>>491
>少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
>名前はスレッドの join であったり db の join であったりたくさんあるよ。
意味の違うjoinをもってきてどうすんの?
今は hogehoge.join(seq) の形でリストやタプルを引数にとるものの話にきまってるだろ。
だれがスレッドのjoinの話をしてるの? Threadのjoinはlistに実装すべきだとかだれかいったの?

話をすりかえんなよ。元の話は "".join(list) より list.join("") のほうが自然かどうかという話だろうが。
listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
そこをおまえがセパレータが文字列じゃないjoin()もあるとか言い出したんだろ。
だからセパレータで文字列を使わないjoin()や、文字列以外での連結を行うjoin()は実際にあるのかと聞いたら、スレッドのjoinを挙げるなんて、バカすぎるわ。
リストやタプルの要素を連結する話なのに、スレッドやDBが関係あるわけないだろ。
「文字列以外の場合も考えられる」といっているけど、結局は具体例挙げられなくて、苦し紛れにjoinがつくものを挙げただけじゃんか。

おまえ反論したいだけだろ。「多重継承があるからsuperにはクラス名が必要」とか、いちいち理由をねつ造すんなよ。
つうかPythonistaはこんなやつほっとくなよ。Python界の恥さらしだろ。身内の恥は身内でなんとかしてくれ。

498 :デフォルトの名無しさん:2009/06/10(水) 00:47:47
Python FAQにjoinのこと載ってあった。

4.8 Why is join() a string method instead of a list or tuple method?
(なんでjoin()はlistやtupleのメソッドじゃなくてstringのメソッドなの?)
ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

やっぱりみんな疑問に思うよな。思わないやつもいるけど。

FAQの答え
This method can be used with any argument which obeys the rules for sequence objects, including any new classes you might define yourself.
(このメソッドは、シーケンスオブジェクトのルールに則った引数なら何でも使うことができます。あなた自身が定義した新しいクラスでも構いません。)

つまりlistやtuple以外でも、sequenceのように振る舞うものなら何でもjoinできるようにするために、joinをlistではなくstrのメソッドにしているわけだ。
>>477の通りだな。

Rubyだとmix-inがあるから、任意のクラスでEnumerableをincludeしてやればArrayじゃないものでもjoinが使えるようになるけど、
Pythonではそうするかわりに引数を抽象化することで、繰り返し可能であればなんでもjoinで使えるようになるということか。
これならjoinがstrのメソッドである理由として納得できるな。
Pythonでは多重継承できるんだからMix-inも使える。だからEnumerableを導入することは技術的には可能だけど、iteratableを引数にするという方法も悪くないね。

これでスッキリした。Pythonいいね!
あとは多重継承が??、joinは文字列を対象にしたメソッドだから??、と、間違った理由をねつ造するバカを排除してくれ。
ほんとの理由を知らないくせに、分かったふりして語るなよな。答えしらないんなら出てくんな。
おまえリアルでも知ったかぶってるだろ。ほんと迷惑。


502 :デフォルトの名無しさん:2009/06/10(水) 01:13:40
>>498
一つの理由を見つけただけですべてを判った気になるな。
ちゃんとそのFAQの最後に、
Because this is a string method it can work for Unicode strings as
well as plain ASCII strings. If join() were a method of the sequence
types then the sequence types would have to decide which type of
string to return depending on the type of the separator.
って書いてあるだろーが。

>>477,495 が正解であると同時に、「strのjoinだからstr.join」というのも
正解だ。

Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
join_to_mystr なんてメソッドを Enumerable に追加するのか?
似たものを追加するときに同じ方法を一貫して使えるのが
正しい方法だ。

511 :デフォルトの名無しさん:2009/06/10(水) 13:52:20
>>502
それはダウトだろう。
今のjoinは単に u'a' + '' + u'b' + '' + u'c' のようなものだろ。

>>> ''.join([u'a',u'b',u'c'])
u'abc'

「strのjoinだからstr」なんてことはない。
もしそうなら
''.join([1,2,3]) だって要素をすべてstr()にしてからjoinしてくれてもいいけど、ぜんぜんそうなってない。
どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

Pythonの仕様上、joinをstrのメソッドにする理由はわかるけど、それが自然かどうかというのはまた別の話。


http://hibari.2ch.net/test/read.cgi/tech/1203557046/l50人気ブログランキングへ