Pythonのお勉強 Part50

**デフォルトの名無しさん** · 2014/10/17(金) 00:41:32.40

Pythonオフィシャルサイト
http://www.python.org/
日本Pythonユーザ会 (※英語わかる人は上記のオフィシャルの方を見ることをお薦めします)
http://www.python.jp/
まとめWiki
http://python.rdy.jp/
関連スレ
http://find.2ch.net/?BBS=ALL&;TYPE=TITLE&STR=python
Pythonのお勉強 Part49
http://peace.2ch.net/test/read.cgi/tech/1387528488/

日本語の扱いで戸惑ったらこちらをどうぞ（バッドノウハウ集で笑える）
ttp://speirs.blog17.fc2.com/blog-entry-4.html
ttp://atomic.jpn.ph/prog/etc/encode.html
ttp://d.hatena.ne.jp/kakurasan/20100330/p1

ttp://pc11.2ch.net/test/read.cgi/tech/1217836194/339
339 ：デフォルトの名無しさん：2008/08/23(土) 08:36:00
PythonのUnicodeEncodeErrorを知る
ttp://lab.hde.co.jp/2008/08/pythonunicodeencodeerror.html

よくまとまってた。あとで読む

**デフォルトの名無しさん** · 2014/11/30(日) 02:14:37.61

>>151
すみません。typo があったので訂正します。

s/cord/code/;
↑　perl ですみません。

re.sub('cord','code', item)
↑　python だとこんな感じでしょうか？

Python チュートリアルと Perl 言語リファレンスの目次に「正規表現」の記載がなくて、
挫折しそうになりました。 Python　標準ライブラリの目次に正規表現　をみつけて一安心。
うーむ、ライブラリなのですね。。。

おやすみなさい。

**デフォルトの名無しさん** · 2014/11/30(日) 05:17:22.58

馬鹿には無理

**デフォルトの名無しさん** · 2014/11/30(日) 05:30:46.36

>>151
pythonにはtimeitという計測ツールもある。
ipythonなら%timeit

**デフォルトの名無しさん** · 2014/12/02(火) 23:50:02.60

perlで、処理したものはハッシュに登録して、2回目からはやらない、
みたいなことをよくやるんだけど
if (!$done{$item}) {

同じことをpythonでやろうとすると、どうしてもtryしないといけなくなる
try:
　if(done[item]):
　　pass
except KeyError:

そういうもの?

**デフォルトの名無しさん** · 2014/12/02(火) 23:54:44.97

if item not in done: do_something(item)

**デフォルトの名無しさん** · 2014/12/03(水) 00:20:47.52

has_key が覚えられない
そもそも、EAFPでないし

**デフォルトの名無しさん** · 2014/12/03(水) 03:34:45.76

if item in done: pass

**デフォルトの名無しさん** · 2014/12/03(水) 03:35:36.42

has_key は deprecated

**デフォルトの名無しさん** · 2014/12/06(土) 09:06:25.05

>>155
>perlで、処理したものは
perl歴10年以上で、2年前にpythonに移行
しました。このような質問とその回答は、
とても参考になります。感謝、感謝！

**デフォルトの名無しさん** · 2014/12/06(土) 09:25:07.43

>>155
item.getも、なければデフォルト返す。けっこう人のコードでも見かける。perlの例はこっちに近い気がする。

**デフォルトの名無しさん** · 2014/12/06(土) 10:06:25.40

except側にメインの処理が来るのが嫌なんだよな

**デフォルトの名無しさん** · 2014/12/06(土) 10:17:49.65

初回という例外であれば、exceptも有りとしている。
ただjavaとか例外処理のコストが気になる言語の場合はやらないな。pythonはサンプルコードでよく見かけるから使ってるけど、コストはどうなんだろうか。

**デフォルトの名無しさん** · 2014/12/06(土) 12:05:45.84

pythonも馬鹿に出来ないと思うよ。調べてないけど
ただ内部的にexceptとかfinally,with使うのは当たり前だから気にしても仕方ない

**デフォルトの名無しさん** · 2014/12/06(土) 12:22:20.08

イテレータ1回舐めるごとにかならずStopIteration投げてるし

dict.set_defaultがvalueしか取らないのが俺は気になる
funcも取って欲しい

**デフォルトの名無しさん** · 2014/12/06(土) 15:37:39.38

例外処理ってどの言語でもコストが高いと予想
全ての文にif付けながら実行してるようなもんでしょあれ

**デフォルトの名無しさん** · 2014/12/06(土) 15:42:45.20

えっ

**デフォルトの名無しさん** · 2014/12/06(土) 15:52:30.13

>>166
んなわけない

あんたが言ってるのは途中でreturnするかもしれない関数で全ての文にif付けて実行してるようなもんでしょって言ってるのと同じだよ。

**デフォルトの名無しさん** · 2014/12/06(土) 16:18:14.87

s = 0
for x in (1, 2, 3, "hoge"):
　s += x
return s

例えばこのfor文の中の s += x で、例外を補足するには毎回xが加算できるかをチェックする必要がある
ということを言いたいのではなかろうかと。

**デフォルトの名無しさん** · 2014/12/06(土) 16:18:22.30

どんな言語でもエラーの判定はしながら実行してる
それで止まってしまうか例外として救えるかが違うだけで

どんな言語でもってことはないか
何も考えずにリソース破壊して終わりな言語はそれまでだけど、
それを軽くていいとは思えない

**デフォルトの名無しさん** · 2014/12/06(土) 16:20:34.40

例外処理という単語が指す対象による

例外ブロックを作ったことによる効率低下は大したことない
一部の最適化ができなくなるくらいだから

一方、実際に例外を投げたなら、どの言語でもそれなりのコストを生じる

**デフォルトの名無しさん** · 2014/12/06(土) 16:29:48.62

０除算は例外出るので有名だけど
いちいちif文なんか実行してないから

**デフォルトの名無しさん** · 2014/12/07(日) 02:49:25.06

話の流れがわかってない子がいるみたいだね

**デフォルトの名無しさん** · 2014/12/07(日) 05:08:55.57

ifより例外のほうが重いイメージ

**デフォルトの名無しさん** · 2014/12/07(日) 10:45:35.98

お前はたぶん馬鹿だから無理だろうなというイメージ

**デフォルトの名無しさん** · 2014/12/07(日) 10:49:56.50

ぶっちゃけPythonで例外のコスト気にするようなプログラム書いたことねえよという事実

**デフォルトの名無しさん** · 2014/12/07(日) 12:51:19.52

まあループ最適化の脱出条件に例外使えば
最適化できるという誤解は誰もが通る道だわな

**デフォルトの名無しさん** · 2014/12/07(日) 12:54:25.49

PythonにもEffectiveJava的な本があるといいね

**デフォルトの名無しさん** · 2014/12/07(日) 13:12:03.36

そういった例外の使い方は例えばjvmでやると標準イデオムと比べて70倍程度は遅くなる
可読性もデバックのやりやすさも捨ててやることじゃない
10年以上前には話題に登ってて覚えてたんだが
pythonのvmは2001年時点のjvmより
おバカなのか？

**デフォルトの名無しさん** · 2014/12/07(日) 13:15:52.02

VMってかCPythonのインタプリタの実装は
かなり馬鹿正直、というか原始的なものだよ

**デフォルトの名無しさん** · 2014/12/07(日) 13:17:41.90

でもおじさんも計測してないや
pythonだとひょっとすると例外の方がはやいかもね

**デフォルトの名無しさん** · 2014/12/07(日) 13:30:04.59

多重ループ抜けるのにおもむろにオレオレエラー投げることはある

**デフォルトの名無しさん** · 2014/12/07(日) 13:32:59.51

PEP234でイテレータの終了判定にStopIterationを採用したことについて

> It has been questioned whether an exception to signal
> the end of the iteration isn't too expensive.

と述べられてる。
あまりコストが高くはなかったとはいえ、低いわけではない。
しかし続きを読むと分かるように、実装をシンプルに行えるメリットを彼らは選んだ。

**デフォルトの名無しさん** · 2014/12/07(日) 13:53:30.07

コストなんざプロセッサが速くなれば屁でもなくなる
でも、コストを重視した設計やコードのツケはずっと残る

**デフォルトの名無しさん** · 2014/12/07(日) 14:11:22.03

どうかなー2倍速かったらクラスタのインスタンス数2分の1にできますよ
一概に容認されうるものじゃないと思うね

**デフォルトの名無しさん** · 2014/12/07(日) 14:15:51.13

http://ideone.com/MfOOfM
数値配列末尾に文字列入れて
意図的に例外で落とすようにしたらふつうのループの２倍程度遅い
でもif+型チェックよりは例外のほうが早かった

なんとも微妙な・・・

**デフォルトの名無しさん** · 2014/12/07(日) 17:17:03.41

8おめこ

**デフォルトの名無しさん** · 2014/12/07(日) 18:17:38.73

>>186
例外が発生しなければ try/except のコストは極めて低いので、めったに発生しない例外ならば
例外を扱ったほうが良いというのFAQのどっかにあったね。

**デフォルトの名無しさん** · 2014/12/07(日) 19:32:02.09

try/except事態は早くてスタックフレームの巻き戻しとか重い操作は raise の時にやるんだよね

**デフォルトの名無しさん** · 2014/12/07(日) 22:39:07.66

scipyのcurve_fitで、収束が悪くてある計算時間を超えたらスキップさせて次に飛びたいんですけど、どうしたら良いでしょうか？

**デフォルトの名無しさん** · 2014/12/08(月) 07:36:33.23

>>182
C# だけど、まさにそのコード書いたばかりだ w

**デフォルトの名無しさん** · 2014/12/08(月) 09:59:10.61

今までみたPythonの例外処理で一番面白かったのはこんなの
http://atomic.jpn.ph/prog/etc/encode.html
http://speirs.blog17.fc2.com/blog-entry-4.html
http://d.hatena.ne.jp/kakurasan/20100330/p1

**デフォルトの名無しさん** · 2014/12/08(月) 10:14:48.98

>>192
エンコードが不明な文字列を片っ端からデコード試して
上手くいった奴が正解なんだよな
モヤモヤするけどね

**デフォルトの名無しさん** · 2014/12/08(月) 10:57:48.21

エンコードが成功とか失敗とかどうやって判断してるか不思議なんだけど
人間だったら文字化けしてるの見て違うって判断できるけど

**デフォルトの名無しさん** · 2014/12/08(月) 11:17:03.49

もちろん例外が出ない意地悪な文字列を送り込むことは可能
あと例外出させるのにも判定の順番が微妙に影響する
どのコードで先にエンコードしてみるかっていうのが結構重要

**デフォルトの名無しさん** · 2014/12/08(月) 11:20:00.98

あと例えば送られてきたメールに
「ーソЫⅨ噂浬欺圭構蚕十申曾箪貼能表暴予・・・」
っていう文字列を発見して

「文字化けしてるっ！」て騒ぐひともいるし
「ああテストしてんだな」って暗黙の了解するひともいる

**デフォルトの名無しさん** · 2014/12/08(月) 11:21:52.23

>>195 の訂正
エンコードじゃなくてデコードと言うべきか

**デフォルトの名無しさん** · 2014/12/08(月) 12:22:31.05

>>194
対応するコードがエンコード先の領域外、未定義だったら失敗でいいんじゃないか。
nkfみたいにマッピングしてるとこもあるかもだけど。

**デフォルトの名無しさん** · 2014/12/08(月) 21:25:30.06

どうもありがとう
> 対応するコードがエンコード先の領域外、未定義だったら失敗
これだったらたしかに失敗ははっきりするね
それにあてはまらない場合もあってそのときは
けっこう微妙な判定をしてるってことかな

**デフォルトの名無しさん** · 2014/12/09(火) 08:02:03.59

ファイルを読み込む時には、バカの一つ覚えのように
decode('utf8')を行ってきましたが、正規表現の処理
をしない場合には必要ありませんよね？

**デフォルトの名無しさん** · 2014/12/09(火) 08:05:14.29

ああー馬鹿の一つ覚えですねそれ

**デフォルトの名無しさん** · 2014/12/09(火) 08:22:35.48

古来ダメ文字問題とか起こしてたのはこいつらです

**デフォルトの名無しさん** · 2014/12/09(火) 14:11:10.31

文字コードとかpython3になったらトラブル減るからいいやと、真面目に取り組む気がしない。
そう思って数年、未だに2系…。

**デフォルトの名無しさん** · 2014/12/09(火) 19:17:54.02

『業務に役立つPerl』っていう本に「日本語を扱うための基本三原則」っていうのが出てたんだけど、
Pyhonも基本この考え方でいい？（ソースコードは文字コードさえちゃんと指定しとけば何でもいいという理解だけど）

・原則1：外部から入力された文字列はデコードして内部文字列に変換する
・原則2：外部へ出力する文字列はエンコードしてバイト文字列に変換する
・原則3：ソースコードはUTF-8で保存し、utfプラグマを有効にする

**デフォルトの名無しさん** · 2014/12/09(火) 19:37:38.16

>>204
バイト文字列って何だろ？
バイナリファイルのこと？

**デフォルトの名無しさん** · 2014/12/09(火) 19:51:55.53

>>205
当該本には

「バイト文字列」は、「バイナリ表現」「オクテット文字列」
「バイトストリーム」「バイト列」などと呼ばれることがあります。

バイト文字列はPerlから見た場合は単なるバイト列のように見えます。
知っているのはプログラマだけで、Perlはそれが文字列であるかどうかを知りません。

と書いてあります。

**デフォルトの名無しさん** · 2014/12/09(火) 20:03:39.61

perlのそういうのが嫌で他の言語を探してpythonを試してるのに

**デフォルトの名無しさん** · 2014/12/09(火) 21:35:24.14

>>206
やっぱりテキストをバイナリデータに変換して外とやりとりすべし、という風に読めるな
だとしたら、その原則は言語に関係ないよ
メインフレームなど異質なアーキテクチャのコンピュータまで視野に入れれば、バイナリで
データをやりとりした方が無難という一般論に近い話だ
PC同士、ましてWindows同士ならば、cp932のテキストのままで何の問題もない
むしろutf-8などという後から出てきたコードに変換する方が恐い

**デフォルトの名無しさん** · 2014/12/09(火) 22:18:44.43

今頃何を言ってるんだ？

**デフォルトの名無しさん** · 2014/12/09(火) 22:24:28.18

>>209
今やっちゃいけない話なのか？

**デフォルトの名無しさん** · 2014/12/09(火) 22:54:18.19

>>204
Python2ならそれと同じ

# coding: utf8
buf = open(...).read() # bufはstr（バイト文字列）
ustr = buf.decode("cp932") # CP932なバイト文字列をUNICODE文字列に変換
print ustr.encode("utf8") # UNICODE文字列をバイト文字列にして出力

**デフォルトの名無しさん** · 2014/12/09(火) 22:56:16.84

>>210
やってもいいけど、はたから見たら老害でしかないぞ

**デフォルトの名無しさん** · 2014/12/09(火) 23:44:44.11

>>212
そうか。>>208の回答を老害と言ってのける君は、さぞ素晴らしい回答をお持ちなのだろう
ぜひとも>>204に答えてあげてほしい
まさか批判だけして質問には答えないってことはないよね？

**デフォルトの名無しさん** · 2014/12/09(火) 23:51:43.65

今時外とやりとりするのにCP932推奨とか老害以外の何者でもないな。

**デフォルトの名無しさん** · 2014/12/10(水) 00:01:59.64

>>213

>>211 に十分な答えが書いてある。
入力でデコード出力でエンコード

老害さん以外誰も「Windowsだったら中でCP932使ってるから外に出すときもそのままで問題ないUTF-8に変換なんて恐ろしい」なんて事は書いてない

**デフォルトの名無しさん** · 2014/12/10(水) 00:05:37.30

>>213
>>204 で問題ないだろ
何を言ってるんだよ w

**デフォルトの名無しさん** · 2014/12/10(水) 02:01:12.95

utf8だとメモ帳て文字化けするから
cp932に全部代えてくれとか要望でたりする

**デフォルトの名無しさん** · 2014/12/10(水) 02:08:07.23

変換するツールを作ってくれ、のがいろいろ使えて便利だと思うんだけどなぁ。

**デフォルトの名無しさん** · 2014/12/10(水) 02:30:51.47

文字コードにある程度ルーズでもなんとかなるpython3さん流行れ

**デフォルトの名無しさん** · 2014/12/10(水) 02:37:11.79

Python2はフォーク(ていうかごっそり移動して)して別言語になれ。
これがwin-win。

**デフォルトの名無しさん** · 2014/12/10(水) 03:21:24.95

中間コードに変換すりゃいいよ

**デフォルトの名無しさん** · 2014/12/10(水) 03:42:57.87

よし、中間にうにこーどつかうぞー

**デフォルトの名無しさん** · 2014/12/10(水) 05:05:58.97

Ethernet経由で流れてくるセンサデータ（パケット）を
Python 2.7 or 3以降で処理したいのですが、
丁度いいパッケージはありませんか?
.pcap形式で一旦溜めずに、逐次処理できる方法を
探してます。

当方Win7 64bit、センサはたとえば
北陽UTM-30LX-EWを想定しています。

**デフォルトの名無しさん** · 2014/12/10(水) 07:20:42.27

>>217
いつの時代のメモ帳だよ w

**デフォルトの名無しさん** · 2014/12/10(水) 07:42:08.52

たぶんbomがついてないのだろう

**デフォルトの名無しさん** · 2014/12/10(水) 08:04:12.84

>>223
TCP か UDP か分かんないけど、
こんなもんでどう？

Lib/http/server.py
Lib/socket.py
Lib/socketserver.py

標準でどうでしょう？
最初は中を覗いてみるのをお勧めする。

**デフォルトの名無しさん** · 2014/12/10(水) 08:22:01.95

bomつきutf8とかいみふめいなんだけど？

**デフォルトの名無しさん** · 2014/12/10(水) 08:33:52.77

>>227
意味不明なのはいいけど、頑なに BOM を目の敵にするのはやめてくれ
流通しちゃってるんだから、書けなくていいから読み取りは対応しろよ...

**デフォルトの名無しさん** · 2014/12/10(水) 08:52:47.05

突っぱねる権限があるならいいだろ
有象無象の雑魚なら発狂しとけ

**デフォルトの名無しさん** · 2014/12/10(水) 09:16:51.66

どうもありがとう
Python2なら同じ考え方でいいんだね

Python3だとどうなるのかな
書き方が違うだけで同じことはできるみたいだけど
文字コードにある程度ルーズでもなんとかなる、よりも
多少面倒でもこれさえしとけばOK、ていう原則がはっきりしてるほうが
書く方は楽だと思うんだけど…でも3のほうが文字コードの扱いについては進歩してるんだよね？

#coding: utf8
ustr = open(encoding="cp932").read()
print(ustr.encode("cp932"))

**デフォルトの名無しさん** · 2014/12/10(水) 09:59:22.81

>>209-210

>208 のは
前半はそれで合ってるが最後の一文で台無しだな

SJISで出力すると内部コードの中にSJISに変換できない文字列が含まれてると死ぬ
UTF-8なら少なくともその問題はない

**デフォルトの名無しさん** · 2014/12/10(水) 10:06:29.84

>>227
BOM付UTF-8がイミフなのは同意だが
MSが推奨してるっぽいな
メモ帳とかVisualStudioとか
もうMSを見捨てる時期に来てる

**デフォルトの名無しさん** · 2014/12/10(水) 10:09:51.61

>230
printの中でencodeは好ましくないと思う
せめて
print(ustr)
か
sys.stdout.write(ustr.encode("cp932"))
のどちらかだけ(両方でも良いけどこの2つのどちらかって意味)を使うべき

**デフォルトの名無しさん** · 2014/12/10(水) 12:34:20.48

>>231
> 前半はそれで合ってるが

ここにも老害かよ
早く引退しろよ

**デフォルトの名無しさん** · 2014/12/10(水) 16:41:38.28

いまどきはテキストだろうが何だろうが圧縮で転送だよな
エンコード相違の問題の発生しようがない

**デフォルトの名無しさん** · 2014/12/10(水) 17:29:42.68

つまんねーギャグだな
生きてる価値なし

**デフォルトの名無しさん** · 2014/12/11(木) 01:28:31.04

>>233
bstr = ustr.encode("cp932")
print(bstr)

ならいいですか？

**デフォルトの名無しさん** · 2014/12/11(木) 05:24:02.53

>>237
だめ

**デフォルトの名無しさん** · 2014/12/11(木) 05:48:35.51

どういう理由だからダメなのか書いてくれよ
ここの人たち、レスがごくわずかなうえに不親切だよな

**デフォルトの名無しさん** · 2014/12/11(木) 07:07:17.75

実際に試してから言えよ
python3のprintはbytesをそのまま出力しないなんて実行すりゃ一発でわかるだろ

**デフォルトの名無しさん** · 2014/12/11(木) 07:12:44.33

馬鹿ですか？
立っている奴は親でも使えって言うでしょ
あんた親ですらないし
生きている限りは俺の役に立てよ
分かったか？スットボケ野郎

**デフォルトの名無しさん** · 2014/12/11(木) 07:27:33.17

10年以上使ったperlからpythonに
乗り換えて2年だが、日本語エンコ
ード関連のエラーが全体の6割程度
という感じ。ただ、perlに比べて
pythonは圧倒的に分かりやすいの
で、そのエラーも直ぐに解決できる。
　
　

**デフォルトの名無しさん** · 2014/12/11(木) 07:31:45.14

なんで ++ ないの?

**デフォルトの名無しさん** · 2014/12/11(木) 07:49:25.24

お前のために誂えた言語じゃないからだよ

**デフォルトの名無しさん** · 2014/12/11(木) 07:52:45.08

>>243
http://stackoverflow.com/questions/3654830/why-are-there-no-and-operators-in-python

**デフォルトの名無しさん** · 2014/12/11(木) 07:57:54.58

=+1と変わらないし、あっても意味がありません(1文字でもタイプ数が増えると指が折れる体質というなら別ですが)
完全にオリジナルの理由については古いメーリングリストを参照するか、グイドに聞いてください
我々は国語の先生じゃありませんから、作者の心情など知りません

**デフォルトの名無しさん** · 2014/12/11(木) 08:30:20.10

>>243
Rubyも同じこと言ってた

**デフォルトの名無しさん** · 2014/12/11(木) 09:55:41.16

>>240
試してみたけどちゃんとバイト列を出力するよ

>>> print('感動巨編'.encode('utf-8'))
b'\xe6\x84\x9f\xe5\x8b\x95\xe5\xb7\xa8\xe7\xb7\xa8'

**デフォルトの名無しさん** · 2014/12/11(木) 10:27:19.77

>>246
> =+1と変わらないし

バグ作り込んでるんじゃねーよ w

**デフォルトの名無しさん** · 2014/12/11(木) 14:45:55.70

>>248
それがどうかしましたか？

**デフォルトの名無しさん** · 2014/12/11(木) 15:16:27.95

printの引数はunicode文字列ってそんなに難しいこと？