Pythonについて（アンチ専用）

**デフォルトの名無しさん** · 2008/02/21(木) 10:24:06

Pythonが嫌いな人のためのスレッドです。

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

**デフォルトの名無しさん** · 2008/02/26(火) 08:24:45

知ってるよ

77 ◆MVveTA3boE · 2008/02/26(火) 08:55:08

>>78
お前だれだ？
トリップつけとく

**デフォルトの名無しさん** · 2008/02/26(火) 09:21:19

>>77
Lisper ?

**デフォルトの名無しさん** · 2008/02/26(火) 11:45:51

%の優先順位が無駄に強すぎてイラつく

print "%d" % 3 + 5
これはエラー

print "%d" % (3 + 5)
こうしないとダメ

print "%d"% 3 + " is the answer."
とかするときのためなのかもしれないが、こんな見にくいのこそ
print ("%d"% 3) + " is the answer."
とか
print "%d is the answer." % 3
ってやるから必要ないし。

**デフォルトの名無しさん** · 2008/02/26(火) 12:25:45

%は演算子なのさ。
"%d" % 3 + 5の%は，文字列を左辺に，数値を右辺に取って，結果として文字列を返す。
その後文字列に数値を足そうとしているのでエラーになる。
それだけのこと。超シンプル。

**デフォルトの名無しさん** · 2008/02/26(火) 12:26:28

演算子の優先順位は型によって変わらないから
数値型とか考えると % が + よりも強いのは自然だと思うが

**デフォルトの名無しさん** · 2008/02/26(火) 12:27:20

文字列の場合は % の右辺は常に括弧で囲むようにするといいよ

**デフォルトの名無しさん** · 2008/02/26(火) 12:28:25

なにこの協力的なアンチスレ(wwwwwwwwwwwww

**デフォルトの名無しさん** · 2008/02/26(火) 12:59:25

ああ、昔
print '%s%s%s' % A, B, C
みたいなのでハマったの思い出したよ。
タプルは括弧いらないんじゃなかったのか？って。

**デフォルトの名無しさん** · 2008/02/26(火) 13:06:17

ここは頭の弱い人はPythonを使えないことを証明するためのスレですね(w

**デフォルトの名無しさん** · 2008/02/26(火) 13:39:29

変な挙動だから、よく知らないと戸惑うというだけの話でしょ。

**デフォルトの名無しさん** · 2008/02/26(火) 14:20:13

挙動が変なのは82の頭。

**デフォルトの名無しさん** · 2008/02/26(火) 16:00:20

Python脳ではないことが変の定義なら、確かに

**デフォルトの名無しさん** · 2008/02/26(火) 16:11:28

演算子の優先順位云々ってのは算数レベルの知識だってことにいいかげん気付けよ。

**デフォルトの名無しさん** · 2008/02/26(火) 16:24:12

タプルを自動展開するフォーマッティングはGuido とかも問題を感じてて
たとえば次みたいなときに何かおかしい

>>> "%s"%1
'1'
>>> "%s"%(1,)
'1'
>>> "%s"%((1,),)
'(1,)'

ということが指摘されてて、実際3.0ではこの仕組みは無くなる。

>>87
タプルが括弧いらないのはその通りだけど、
演算子の順位としては最弱(and or より更に弱い)なので、
その場合後ろの方が独立したexprになってしまう。
まあ、確かにカンマと+の順位とか普段考えないので嵌るといえば嵌る

**デフォルトの名無しさん** · 2008/02/26(火) 16:45:03

>>92
Python脳の人がPythonに一切疑問を抱かないのは知ってるから、
そんなに一所懸命「後戻りできなくなったボクの脳を見て！」ってアピールしなくていいです。

**デフォルトの名無しさん** · 2008/02/26(火) 16:57:25

と、さんすうにも四苦八苦なゆとりが申しております。

**デフォルトの名無しさん** · 2008/02/26(火) 18:01:31

算数が平仮名なら、それより先に四苦八苦を平仮名にしないと
演出としてダメダメだと思うよ。

**デフォルトの名無しさん** · 2008/02/26(火) 19:21:28

は？

**デフォルトの名無しさん** · 2008/02/26(火) 21:11:40

>>96
大丈夫かお前

**デフォルトの名無しさん** · 2008/02/26(火) 21:46:47

と、こくごに四苦八苦なゆとりが申しております。

**デフォルトの名無しさん** · 2008/02/26(火) 23:19:11

3.0っていつごろ出る？

99 · 2008/02/26(火) 23:19:57

だれかわたしに挑戦しませんか？w

**デフォルトの名無しさん** · 2008/02/27(水) 00:06:45

>>100
ttp://www.python.org/dev/peps/pep-3000/

**デフォルトの名無しさん** · 2008/02/27(水) 05:17:10

>>101
アホを相手にする人はいません。

**デフォルトの名無しさん** · 2008/02/27(水) 06:06:22

誰もお前の相手なんかしない、という内容で相手してる奴の頭って・・・

**デフォルトの名無しさん** · 2008/02/27(水) 06:15:05

>>104
言うことを聞かないからといって何も注意しないのは罪だから。

勝手に事情聴取した防衛省とかね。

まあ、事故のときはまず身内に相談するのが当たり前ではあるけど。

**デフォルトの名無しさん** · 2008/02/27(水) 06:28:06

>>int PyRun_SimpleStringFlags( const char *command, PyCompilerFlags *flags)
>>__main__モジュールの中でflags に従ってcommand に含まれる
>>Python ソースコードを実行します。
>>__main__がまだ存在しない場合は作成されます。
>>正常終了の場合は0を返し、また例外が発生した場合は-1を返します。
>>エラーがあっても、例外情報を得る方法はありません。
氏ね
普通に例外情報取得できるようにしろ

リファレンスはまったく詳細を書いていない。
ほとんど役に立たない。クズ同然。

**デフォルトの名無しさん** · 2008/02/27(水) 07:03:37

>>100
西暦3000年

**デフォルトの名無しさん** · 2008/02/27(水) 17:04:28

商業ベースに乗らないマイナースクリプト言語の問題はリファレンスがクズということだな

**デフォルトの名無しさん** · 2008/02/27(水) 17:06:19

そうだな、言語リファレンスが存在しないRubyはクズ言語と言っていいよな。

99 · 2008/02/27(水) 19:36:40

パイソニスタの私がいうのもなんですが、
Pythonは屑言語の1つだと思います。
N88 BASICより使えない駄目言語。

**デフォルトの名無しさん** · 2008/02/27(水) 19:43:37

>>110
それはない

**デフォルトの名無しさん** · 2008/02/27(水) 19:44:22

パイソンにはLINE文もPAINT文もDATA文もないので
ミンメイが描けません！！
こんな屑言語を作った人は死ねばいいと思います！

**デフォルトの名無しさん** · 2008/02/27(水) 19:49:27

>>112
import turtle

**デフォルトの名無しさん** · 2008/02/27(水) 20:12:10

http://coreblog.org/ats/turtle-python-standard-module

99 · 2008/02/27(水) 20:46:24

Pythonにgotoがない時点で終わってると思います。
また安易にErrorキャッチに頼りやすい。
何が
try
except
だ。楽すぎて死ねるわ。
しかも最初からpdbなんていうデバッガもどきがついてるし

**デフォルトの名無しさん** · 2008/02/27(水) 21:33:19

goto for Python
ttp://entrian.com/goto/

**デフォルトの名無しさん** · 2008/02/27(水) 22:23:25

PLAY文が無い限りBASICには勝てない

**デフォルトの名無しさん** · 2008/02/27(水) 22:26:54

PyAudio

The following only summarizes information from the PyAudio Web page.

PyAudio provides Python bindings for the PortAudio audio I/O library. The current version of PyAudio is V0.1.0, which is alpha quality.

Multi-platform
Package is compilable for MS-Windows, Apple Mac OS X, Linux and cygwin.
Real-time sound acquisition
Unknown
Support for 16KHz sampling rate and >8-bit sound
Unknown.
Sound file processing
Unknown.
Efficiency
Unknown.
Pitch existence and frequency
Unknown.
Formants and their bandwidths
Unknown.
FFT with pre-emphasis and Hamming window
Unknown.
Power
Unknown.

**デフォルトの名無しさん** · 2008/02/27(水) 22:27:49

PyMedia.py

The documentation is very sketchy.

Multi-platform
Package is compilable for MS-Windows, Linux and cygwin.
Real-time sound acquisition
Unknown
Support for 16KHz sampling rate and >8-bit sound
Probably depends upon sound card.
Sound file processing
Yes.
Efficiency
Unknown.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

**デフォルトの名無しさん** · 2008/02/27(水) 22:28:12

MCI.py (from Arik Baratz) together with ctypes.py

Multi-platform
ctypes.py is supported by all 32-bit MS Windows (95/98/NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSD/UNIX-like OSes), WinCE.
MCI.py was designed to communicate with MS-Windows winmm.dll.
Real-time sound acquisition
Unknown.
Support for 16KHz sampling rate and >8-bit sound
Unknown.
Sound file processing
Seems to be able to record to a file.
Efficiency
Commands are sent as strings.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

**デフォルトの名無しさん** · 2008/02/27(水) 22:28:45

ossaudiodev

Multi-platform
Not enough. Implemented in Linux and FreeBSD. Available for a wide range of open-source and commercial Unices. But apparently not for MS-Windows.
Real-time sound acquisition
Blocking reads, by default. Probably can set to non-blocking.
Support for 16KHz sampling rate and >8-bit sound
Seems to depend upon the sound card.
Sound file processing
Use another package for this.
Efficiency
Direct I/O access.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

**デフォルトの名無しさん** · 2008/02/27(水) 22:29:15

Snack

Multi-platform
The same scripts are usable on Windows 95/98/NT/2K/XP, Linux, Macintosh, Sun Solaris, HP-UX, FreeBSD, NetBSD, and SGI IRIX.
Real-time sound acquisition
Yes.
Support for 16KHz sampling rate and >8-bit sound
Yes.
Sound file processing
Yes.
Efficiency
Inefficient - data is converted into string by the Tcl part of the package and then converted back into data by the Python part.
Pitch existence and frequency
Yes. Each 10mSec, using the ESPS method (the ADMF method is available, too).
Formants and their bandwidths
http://www.speech.kth.se/snack/man/snack2.2/tcl-man.html#sound - see the formant subcommand.
FFT with pre-emphasis and Hamming window
See above link - the powerSpectrum subcommand.
Power
See above link - the power subcommand.

**デフォルトの名無しさん** · 2008/02/27(水) 22:31:57

http://wiki.python.org/moin/PythonInMusic

**デフォルトの名無しさん** · 2008/02/27(水) 22:50:00

は？

**デフォルトの名無しさん** · 2008/02/27(水) 22:53:29

PUT文がないとゲーム作れないじゃん。
馬鹿言語かよ＞PYTHON

**デフォルトの名無しさん** · 2008/02/27(水) 23:37:52

Pythonにはブレースが採用されないから
いつまでたっても糞言語。

**デフォルトの名無しさん** · 2008/02/28(木) 09:51:38

ブレースなんてえーだらー

**デフォルトの名無しさん** · 2008/02/28(木) 09:54:41

我ながら全くどうでもいい書き込みだ

**デフォルトの名無しさん** · 2008/02/28(木) 15:33:58

乳thon

**デフォルトの名無しさん** · 2008/02/29(金) 07:01:07

http://news24.2ch.net/test/read.cgi/news5plus/1204187397/

**デフォルトの名無しさん** · 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)

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

**デフォルトの名無しさん** · 2008/03/01(土) 04:44:51

ifp = codecs.getreader('utf-8')(open(src, 'rb'))
ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
ofp.write(ifp.read().encode('euc-jp'))

これもだめでした

**デフォルトの名無しさん** · 2008/03/01(土) 05:02:42

>>131
あきらめろ

hoge = u'髙'
print hoge.encode('euc-jp')

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

**デフォルトの名無しさん** · 2008/03/01(土) 07:29:25

Pythonではしごだかをどう扱うよって話だね
どういう対処法があるのかｗｋｔｋ

**デフォルトの名無しさん** · 2008/03/01(土) 07:39:48

python固有の問題でもないと思うが、
hoge.encode('euc-jp', 'replace')でもしとけば

**デフォルトの名無しさん** · 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()

**デフォルトの名無しさん** · 2008/03/01(土) 16:07:09

>>136
ビンゴです
ありがとうございました

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

**デフォルトの名無しさん** · 2008/03/01(土) 16:12:14

EUCにコードが無い訳じゃないんだよなぁ
fuga = '\xa1\xc1, \xfc\xe2, \xf9\xf5'

**デフォルトの名無しさん** · 2008/03/01(土) 16:15:53

>>137 の2つ目の「～」は「～」でした
読みにくくてすみません

**デフォルトの名無しさん** · 2008/03/01(土) 16:27:28

「～」は統一されていない
ttp://ichi.mo-blog.jp/tedious/2007/05/
ttp://www.mysql.gr.jp/mysqlml/mysql/msg/12432

**デフォルトの名無しさん** · 2008/03/01(土) 16:29:50

ttp://ja.wikipedia.org/wiki/%E6%B3%A2%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5

ここの「UNICODEに関する問題」を見ると泣けてくる

**デフォルトの名無しさん** · 2008/03/01(土) 16:42:34

これみて自分で変換するしかないでしょうね
http://www.ajisai.sakura.ne.jp/~dindi/chrc/ref/wincode2.txt

**デフォルトの名無しさん** · 2008/03/01(土) 20:21:19

>>142
いただいた

**136** · 2008/03/02(日) 03:39:09

>>137
「～」はEUC-JPとUTF-8を相互変換するときのテーブルがOS/言語ごとに違うために
変換できなかったり違うグリフで表示されたりします。

俺はよく使う文字について以下のようなコードでWindows用にそろえてます。

    unification = {
        0x2014: 0x2015, # HORIZONTAL BAR
        0xFF5E: 0x301C, # WAVE DASH
        0x2225: 0x2016, # DOUBLE VERTICAL LINE
        0x22EF: 0x2026, # HORIZONTAL ELLIPSIS
        0xFF0D: 0x2212, # MINUS SIGN
        0xFFE0: 0x00A2, # CENT SIGN
        0xFFE1: 0x00A3, # POUND SIGN
        0xFFE2: 0x00AC} # NOT SIGN

    text = unicode(...).translate(unification)

136の例では ifp.read().translate(...) とすればよいと思われ。

**デフォルトの名無しさん** · 2008/03/02(日) 04:15:41

ごめ、訂正。Windows用にそろえてるんじゃなくて、PythonのEUC-JP/Shift_JIS/ISO-2022-JPコデックが
受け付けるコード値に置換してる、というのが正しいです。

ついでに説明しとくと144のunification（辞書）は、キーはWindowsで日本語入力したときに使われるコード値、
各キーの値はPythonの日本語コデックが受け付けるコード値です。

この8個の文字にOS/言語ごとの変換テーブルの違いが集中しているので、
144の置換をしておくと UTF-8 → EUC-JP/Shift_JIS/ISO-2022-JP 変換時のエラーがだいぶ減るはず。

**デフォルトの名無しさん** · 2008/03/02(日) 06:08:12

蟻が十匹

**デフォルトの名無しさん** · 2008/03/02(日) 09:37:37

ありがとうございました

ひょっとして梶●さんですか？

**デフォルトの名無しさん** · 2008/03/04(火) 14:14:00

hoge = {'a': 4, 'c': 2, 'b': 9}

for k,v in hoge.items():
print k,v

for k,v in hoge.iteritems():
print k,v

なにがちがうんでしょうか？

**デフォルトの名無しさん** · 2008/03/04(火) 14:17:54

ここは質問スレではないんだが

**デフォルトの名無しさん** · 2008/03/04(火) 14:29:07

>>> hoge = {'a': 4, 'c': 2, 'b': 9}
>>> type(hoge)
<type 'dict'>
>>> type(hoge.items())
<type 'list'>
>>> type(hoge.iteritems())
<type 'dictionary-itemiterator'>

**デフォルトの名無しさん** · 2008/03/04(火) 23:21:17

（´∀｀）ノhoge = dict(enumerate(xrange(1000000)))

**デフォルトの名無しさん** · 2008/03/07(金) 21:07:32

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> a
{'hige': 'hage', 'hoge': 'fuga'}
>>> b = str(a)
>>> b
"{'hige': 'hage', 'hoge': 'fuga'}"

ここで文字列 b から hash を復元して
c (= {'hoge': 'fuga', 'hige': 'hage'}) を作りたいのですが
どのように書けばよいでしょうか？

**デフォルトの名無しさん** · 2008/03/07(金) 21:11:56

>>> eval(b)
{'hige': 'hage', 'hoge': 'fuga'}

**デフォルトの名無しさん** · 2008/03/07(金) 21:17:50

Pythonのアンチスレは質問スレになる不思議

>>152
pickle も調べてみる価値がある、かもしれない
オブジェクトをファイルに保存/復元できるライブラリだよ

**デフォルトの名無しさん** · 2008/03/07(金) 21:40:03

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> import pickle
>>> pickle.dumps(a)
"(dp0\nS'hige'\np1\nS'hage'\np2\nsS'hoge'\np3\nS'fuga'\np4\ns."
>>> pickle.loads("(dp0\nS'hige'\np1\nS'hage'\np2\nsS'hoge'\np3\nS'fuga'\np4\ns.")
{'hige': 'hage', 'hoge': 'fuga'}

**デフォルトの名無しさん** · 2008/03/08(土) 02:39:38

そのまま書き出すとこんな感じ？
(dp0
S'hige'
p1
S'hage'
p2
sS'hoge'
p3
S'fuga'
p4
s.
読みやすいといえば読みやすいし
JSONやYAMLに比べると微妙なんだけど
このフォーマットって何か由来あるんですか

**デフォルトの名無しさん** · 2008/03/08(土) 02:57:25

pickleは人間が編集するようなものではないでしょ
フォーマットは pickle.py, pickletools.py あたり?

**デフォルトの名無しさん** · 2008/03/08(土) 03:47:04

FORTHっぽいね

**デフォルトの名無しさん** · 2008/03/08(土) 04:31:54

>>153
python はこれができるからいいんだよね、
昔 perl でこれと同じ関数を2週間ぐらいかけて作ろうとしてた時に、(リファレンスやら再帰やら使って・・・）
python は両方builtin でできると知って、一気にperl 捨てたｗ

**デフォルトの名無しさん** · 2008/03/08(土) 14:50:49

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> '%(hoge)s' % a
'fuga'

とか、

>>> b = {'moge': a}
>>> '%(moge)s' % b
"{'hige': 'hage', 'hoge': 'fuga'}"

とかは便利なのは分かったんですが、

>>> '%(moge[hoge])s' % b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'moge[hoge]'
>>> "%(moge['hoge'])s" % b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: "moge['hoge']"

ネストされたhashへのアクセスは出来ないんでしょうか？

**デフォルトの名無しさん** · 2008/03/08(土) 15:42:01

出来ない

**デフォルトの名無しさん** · 2008/03/08(土) 15:44:51

>>160
代わりにこの辺のTemplate使ってる
ttp://pythonpaste.org/tempita/

**デフォルトの名無しさん** · 2008/03/08(土) 16:19:36

>>161-162
ありがとうございました
おかげでなんとかなりそうです

**デフォルトの名無しさん** · 2008/03/15(土) 00:48:44

ほのぼのとしたアンチスレだな。

**デフォルトの名無しさん** · 2008/03/15(土) 00:53:23

ともすると本スレのほうが殺伐としていて困る

**デフォルトの名無しさん** · 2008/03/15(土) 13:39:38

pythonはとっとと、ソート演算子のオーバーライドをサポートしてくれ。

**デフォルトの名無しさん** · 2008/03/15(土) 13:56:08

演算子?

**デフォルトの名無しさん** · 2008/03/15(土) 14:53:55

組み込みクラスの__cmp__()を変更したいとか？
組み込みクラスはオーバーライドできない実装を受け入れて
サブクラス化するなりして問題解決した方が精神衛生上よい。

**デフォルトの名無しさん** · 2008/03/15(土) 23:10:49

>>166
引数でラムダ式渡すのでは困る理由は何？

**デフォルトの名無しさん** · 2008/03/26(水) 02:08:27

c++ やcommon lispに比べたらモジュールがいろいろ足りない
統計とか数式処理とか
今のままでも便利なんだけど歴史が浅いからね

**デフォルトの名無しさん** · 2008/03/26(水) 06:59:06

>>170
scipyとか

**デフォルトの名無しさん** · 2008/03/26(水) 19:44:01

C++は老害言語。

**デフォルトの名無しさん** · 2008/03/26(水) 20:40:07

老害か。

N88Basicのことかな

**デフォルトの名無しさん** · 2008/03/27(木) 04:21:42

> c++ やcommon lispに比べたらモジュールがいろいろ足りない
スクリプト言語では Perl が一番揃ってそうだな
次が Python かな

**デフォルトの名無しさん** · 2008/03/27(木) 08:03:46

>>174
>スクリプト言語では Perl が一番揃ってそうだな

数はあるが、玉石混淆で使えるモジュールを選ぶのが大変なのがPerl。

**デフォルトの名無しさん** · 2008/03/29(土) 15:27:00

ほしゅ

**デフォルトの名無しさん** · 2008/03/30(日) 12:24:18

age

**デフォルトの名無しさん** · 2008/04/01(火) 07:40:47

おまいら、py3kについてはどう思うよ？
俺はclassic style classが使えない時点で見放したが。