Pythonのお勉強 Part34 - 暇つぶし2ch

Pythonのお勉強 Part3 ..

849:デフォルトの名無しさん
09/09/14 23:42:04
UTF-16ならBELEあるからBOMの必要性がわかるが、
なんでUTF-8にBOMが必要なんだ？

いやとあるスレで、SJISやEUCテキストとの識別を容易にするために
BOM付きUTF-8を提案したのは俺だったりするのだが。

850:デフォルトの名無しさん
09/09/14 23:52:04
BOMはトラブルの元って認識なんだが。

851:デフォルトの名無しさん
09/09/15 00:12:02
Pythonやっぱつかえねーなー

852:デフォルトの名無しさん
09/09/15 00:20:26
BOMはPython関係ねー

853:デフォルトの名無しさん
09/09/15 00:37:51
やっぱRubyだなー

854:デフォルトの名無しさん
09/09/15 00:38:04
UTF-8でソース書くときは
いつも付けてるが。

855:デフォルトの名無しさん
09/09/15 00:45:08
>>850
BOM のせいで shebang がどうさしないとか

856:デフォルトの名無しさん
09/09/15 00:49:52
PythonやPerl、Lispはやってて面白いし使える言語だがRubyだけは使いたくないな
存在価値も無いし

857:デフォルトの名無しさん
09/09/15 02:53:36
Rubyしかありえねえだろ。日本だぞここは

858:デフォルトの名無しさん
09/09/15 03:19:11
俺にとって四国は海外なので無問題。

859:デフォルトの名無しさん
09/09/15 03:20:32
四国と何の関係があるの？

860:858
09/09/15 04:05:24
松江って四国にあると勘違いしちゃった。テヘ

861:デフォルトの名無しさん
09/09/15 05:39:33
松山と間違えたわけか

862:デフォルトの名無しさん
09/09/15 07:48:27
>>843
ありがとうございます、助かります。
ヘッダやライブラリの何かの変数でどちらか判定できそうかと思ったんですが、
そこまでは分かりませんでした。
でも、debian sid x86_64ですが、UCS2っぽいです。
UCS2だとwchar_tを使っているみたいなのでなんとかなりそうです。
ctypes.c_wchar_pも使えそう。

863:デフォルトの名無しさん
09/09/15 08:12:56
withステートメントの意義が分からない

864:デフォルトの名無しさん
09/09/15 08:36:39
スレッドの同期オブジェクトをwithで使えるクラスを書いておくと、めーっちゃ便利。

def something(self):
　通常の処理

　with SynqObj(self.lock):
　　クリティカルセクションな作業
　
　通常の処理

865:デフォルトの名無しさん
09/09/15 09:12:14
>>862
関係ないかもしれないけど gcc で wchar_t って UCS-4 相当というか4バイトじゃなかったっけ？

866:デフォルトの名無しさん
09/09/15 10:39:39
>>862
pyconfig.hに
Py_UNICODE_SIZEってのがある

867:デフォルトの名無しさん
09/09/15 10:48:49
>>860-861
中国はパスポートが必要

868:デフォルトの名無しさん
09/09/15 10:50:14
>>864
thx!

869:デフォルトの名無しさん
09/09/15 11:40:05
あれ、with lock: ... って書けるよね。threadingでもthreadでも

870:デフォルトの名無しさん
09/09/15 12:00:28
with 構文の as は何のため？

871:デフォルトの名無しさん
09/09/15 12:33:02
reStructuredTextをはがしてPlain Textにするモジュールってありますか？

872:デフォルトの名無しさん
09/09/15 13:18:30
>>869
ああ、864は複数のスレッドの呼び分けをログで確認するためにラッパーを介しているだけだから。キニスンナ。
普通はlockオブジェクトを直にwith呼び出ししてかまわない。

>>870
Python 2.6のリリースノート読め！

873:デフォルトの名無しさん
09/09/15 13:44:36
>>871
URLﾘﾝｸ(stackoverflow.com)

874:デフォルトの名無しさん
09/09/15 14:08:01
>>873
サンキュー。
でもドキュメント無いからソースよめってことね…。

875:デフォルトの名無しさん
09/09/15 14:29:11
shebangのこと忘れてたよ

876:デフォルトの名無しさん
09/09/15 14:38:22
rst2xxx -> xxx2txt みたいな経路でいけないかな？

877:デフォルトの名無しさん
09/09/15 16:39:11
Pyhton3.0以降の言語仕様を日本語で解説してるサイトや書籍ってある？

3.0以降の資料が少なすぎて、勉強がさっぱり進まない
やはり英語を覚えるのが先なのか・・・

878:デフォルトの名無しさん
09/09/15 17:24:52
腐るほどあるような気が
Python3.0でググるよりPython3000のほうが多いかも

879:デフォルトの名無しさん
09/09/15 18:29:18
オライリーの第3版初めてのPythonの中でちょっとだけ触れられている

880:デフォルトの名無しさん
09/09/15 18:37:56
>>878
うーん、一部を解説したものしか見つからない
できたら3.1までの仕様変更点を全て網羅している
解説が欲しいんだけど

881:デフォルトの名無しさん
09/09/15 18:56:31
>>880
Python 3.0/3.1のリリースノートを読むのが結局一番早いよ。
Pythonはこの辺とても丁寧。

ところで、
IronPythonに向いた軽量なO/Rマッパーが見当たらなかったので
『100行ちょっとのやる気のないPython製O/Rマッパー』をベースに
実装してみたんだけど、試してみたい人います？

一応、Python/IronPython両用です。

882:デフォルトの名無しさん
09/09/15 19:25:58
>>877
読んでみたけど
URLﾘﾝｸ(docs.python.org)
URLﾘﾝｸ(docs.python.org)
これくらいのボリュームなら自動翻訳でもかなり役立つと思うが。

# この先、仕事でプログラムするなら英語は何れ必要となるだろうからガンバレ
# 最近の翻訳は中国語から順に整備される傾向があるからな・・・

883:デフォルトの名無しさん
09/09/15 19:35:40
>>866
確かにありました。
4になっていました。

>>865
sizeofで確認したところ確かに4バイトでした。
pyconfig.hの記述と一致してます。
UCS2って2バイトだと思ってましたが、
実装上はwchar_tで表現するので4バイトになってるってことなんでしょうか。
UCS4は元が4バイトですよね。
とりあえずPythonではunicode一文字は4バイトと思って良いのかな。
ほんとunicodeとその周辺のエンコーディングはよく分かりません。

884:デフォルトの名無しさん
09/09/15 19:40:43
>>881
柴田さん乙

885:デフォルトの名無しさん
09/09/15 19:47:36
pyconfig.hはautoconfなんかで出力してんじゃないの

886:デフォルトの名無しさん
09/09/15 20:37:03
>>883
ucs4を使うかutf-16を使うかはconfigureオプションで指定して、
sizeof(wchar_t) == 4 && ucs4 の場合か、 sizeof(wchar_t) == 2 && utf-16 の場合にのみ
wchar_t を使う・・・という仕様だった気がする。
Pythonの拡張モジュールを作るときには、wchar_tを直接使うんじゃなくて、
Py_UNICODE を使う。
URLﾘﾝｸ(docs.python.org)

887:デフォルトの名無しさん
09/09/15 22:00:25
>>886
あー、なるほど・・・
とりあえずLinux(gcc)ではi686でもamd64でもwchar_tがあり、
>>865さんの指摘どおり両方とも4バイトでした。

UCS4の場合にはどちらもwchar_tで4バイトですが、
UCS2(UTF-16)の場合にはwchar_tと不一致なので
unsigned shortが使われるようです。
これも両方共2バイトでした。

ということで、Linux(gcc)ではUCS2ならばunsigned shortで2バイト、
UCS4ならばwchar_tで4バイトということですね。
最近のLinuxディストリビューションではUCS4が多いらしいです。
Debian sidでもそうです。

Py_UNICODEを使った方が良いのだと思いますが、
Cで書く部分はできるだけPython独立にしておいて
ctypesからそれを利用したいので、
とりあえずwchar_tを使うことにします。

でもimmutableだからなのか、unicodeをそのまま渡して
中身を変更するような事はすぐにはできないっぽいです。
create_unicode_bufferを使うしかなさそうです。

888:デフォルトの名無しさん
09/09/15 22:08:01
boostPython

889:デフォルトの名無しさん
09/09/16 00:13:28
>>881
プププ、クソ本の著者乙(wwWwwwwWWWwwwWwWwww

890:デフォルトの名無しさん
09/09/16 00:15:28
>>884,889
いや、当の著者の再配布許可が出たところなんだけど。
別に信じないならいいけどさ。

891:デフォルトの名無しさん
09/09/16 00:37:33
884と889は低脳。
みんぱいの人に嫉妬するクソ本作者。

892:デフォルトの名無しさん
09/09/16 00:52:06
またruby房の嫌がらせか

893:デフォルトの名無しさん
09/09/16 09:03:24
大抵の謎の書き込みは >892 で納得できちゃうね

894:デフォルトの名無しさん
09/09/16 09:47:25
Pythonスレはスルー力が有って良いと思う

895:デフォルトの名無しさん
09/09/16 10:48:56
何か書こうと思ったんだけど忘れた

896:デフォルトの名無しさん
09/09/16 12:09:33
逃げるなよ。

897:デフォルトの名無しさん
09/09/16 12:27:59
逃げるが勝ちだな

898:デフォルトの名無しさん
09/09/16 12:41:43
逃げちゃだめだ

899:デフォルトの名無しさん
09/09/16 18:05:00
>>888
ひょっとしてctypesよりboost.pythonの方が良いっていう意味のレスですか？
そうでないとしても、それをきっかけにしてboost.pythonも検討してみました。

boost.pythonとしては、まだunicode文字列を引数としてどう受け渡すのか
方式が定まってないっぽいんですが、とりあえずPyObject* opとして受け取って
PyUnicode_AS_DATA(op)でconst char*として実際のデータバッファのアドレスを取り出して、
それをwchar_t*にキャストして自作のC++関数などに渡せば良さそうです。
C++ではwchar_t*として扱うPython独立なプログラムとして作成して、
引数を渡すところだけはこの変換をするために一枚かぶせる感じです。
unicodeの実装がwchar_tではない場合には困るんすが、C++だし、
とりあえずテンプレート使っておけば後々それほど困らないでしょうし。

これでunicode文字列をC++の中で書き換えることもできました。
boost.pythonって、ほんとに楽にC++とやりとりできますね。

900:デフォルトの名無しさん
09/09/16 18:42:02
>>897
働いたら負けだよな。

901:デフォルトの名無しさん
09/09/16 19:30:48
俺が逃げるまで逃げるなよ

902:デフォルトの名無しさん
09/09/17 06:49:55
はやくにげてえーーーー

903:デフォルトの名無しさん
09/09/17 11:18:04
boost.python前提になると他の言語からも使えるdllにならない

904:デフォルトの名無しさん
09/09/17 11:28:50
Eclipse で Java 開発環境と mingw による C言語での開発
環境をスタンドアロンで持ち歩いてるんですが，
PyDev と Python 実行環境もそんなことができればなぁ
と思ってます．Windows 環境です．

Windows の Python はレジストリに何か登録しているよう
なんで，そういうポータブルなことは難しいでしょうか？

905:デフォルトの名無しさん
09/09/17 11:54:05
URLﾘﾝｸ(portablepython.com)
公式からもリンクされてるからそんなに怪しいものでは無いと思う。
公式からのリンク：URLﾘﾝｸ(python.org)

906:デフォルトの名無しさん
09/09/17 20:32:24
>>903
まずはC++で(Pythonその他から)独立したクラスを作っておけばいいんじゃないですか？

907:デフォルトの名無しさん
09/09/17 21:24:45
unittest.TextTestRunner で複数のテストを次々と実行するトキ，
最初に発生した例外でストップしてほしいんですが，できますか？

908:デフォルトの名無しさん
09/09/18 05:57:29
emacsのpython-mode.elで、ユニコードリテラル中にエスケープせずに文字を書くのと、
エスケープコードを書くのとで、py-execute-bufferの際に別物にされてしまう。
（素のバイトストリング扱いになるらしい）

C-x C-f foo.py
#!/usr/bin/python
# -*- mode: python-mode; coding: utf-8 -*-

print u'あ' == u'\u3042'

C-c C-c => False

$ python foo.py
True

どうしたものか。

909:デフォルトの名無しさん
09/09/18 08:15:29
sys.getdefaultencoding()

910:908
09/09/19 04:44:02
sys.getdefaultencoding() は環境によらず ascii を返すので原因は違うところにあるようだ。
ちなみに locale.getdefaultlocale() はいつでも ('en_US', 'UTF8') が帰る。
C-c ! で ipython を出しておいて C-c C-cすれば普通にターミナルからやるのと同じ挙動に
なったので、それでいいことにしたわ。

911:デフォルトの名無しさん
09/09/19 09:48:33
循環参照してしまうとそのオブジェクトはプロセスの
終了まで解放されない？

class ClassA(object):
　　 def __init__(self):
　　　　 import sys
　　　　 sys.stderr.write("ClassA.__init__(...) %s\n" % str(self))
　　 def __del__(self):
　　　　 import sys
　　　　 sys.stderr.write("ClassA.__del__(...) %s\n" % str(self))

class ClassC(object):
　　 def __init__(self):
　　　　 import sys
　　　　 sys.stderr.write("ClassC.__init__(...) %s\n" % str(self))
　　　　 self.a1 = ClassA()
　　　　 self.a2 = ClassA()
　　　　 self.a1.a2 = self.a2
　　　　 self.a2.a1 = self.a1

　　 def __del__(self):
　　　　 import sys
　　　　 sys.stderr.write("ClassC.__del__(...) %s\n" % str(self))

これで ClassC のインスタンスを作ると，
ClassA.__del__ は永遠に呼び出されない．
せめてプロセスの終了時には呼び出されると思ってた．

912:デフォルトの名無しさん
09/09/19 09:57:26
ふうむ，ガベージコレクタが __del__ の
呼び出し順を決定できないからか．
そもそもデストラクタがあるのに循環参照が
起きるような設計をするなということだよな．

913:デフォルトの名無しさん
09/09/19 10:45:10
>>908
C-x C-f foo.py
#!/usr/bin/python
# -*- mode: python-mode; coding: utf-8 -*-

print u'あ' == u'\u3042', hex(ord(u'あ')), u'あ'.encode('utf8')

C-c C-c => False (どうなりますか?)

914:908
09/09/19 17:52:16
>>913
C-c C-c => False 0x20
と出ます。u'あ'.encode('utf8') はエラーも出さずに飲み込まれてしまっているみたい。ちなみに
print u'あ’ -> なにも表示されない、
print u'\u3042' -> UnicodeEncodeError: 'ascii' codec can't encode character u'\u3042'...
となる。あらかじめC-c ! でipythonのバッファを出しておけばこれらの問題は起きない。

915:デフォルトの名無しさん
09/09/19 19:40:27
>>911
そういうのって明示的に循環参照削除するメソッド作って呼び出すもんじゃないの？
と最近Pythonに興味もったPerl使いが言ってみる。

Perlだと参照を弱める(リファレンスカウント減らす)方法あるけど、
Pythonだと似たような方法有るのかな。

916:デフォルトの名無しさん
09/09/19 19:57:07
del

917:デフォルトの名無しさん
09/09/19 19:58:55
boost だと weak_ref とかの弱参照なスマートポインタがあるよな

918:デフォルトの名無しさん
09/09/19 20:00:17
Pythonにもweak_refあるけど、やっぱり明示的に参照切るほうが多いかな。
weak_refは余計なコストかかるし。

919:デフォルトの名無しさん
09/09/19 20:08:20
>>915
URLﾘﾝｸ(www.python.jp)

これ、絶対入ってるよね。
（文中の『デフォルトでは入っています』に対するレス）

920:デフォルトの名無しさん
09/09/19 22:27:55
infopile思ったより本格的だった
朝から使ってたけど普通に常用メーラで行けそう

921:デフォルトの名無しさん
09/09/19 22:40:02
C++は元々が自前でメモリ管理しなきゃいけないから余計にああいうの欲しくなるけど
最低限で済むPythonではやはり最低限で良いと思うやね

922:デフォルトの名無しさん
09/09/19 22:54:52
>>920
宣伝乙

923:デフォルトの名無しさん
09/09/19 23:47:44
>>920
Windowsだけなんだっけ？

924:デフォルトの名無しさん
09/09/20 23:35:03
>>> L=[]
>>> L[:]
[]
>>> L[:]=[1,2,3]
>>> L
[1, 2, 3]

リストの初期化がなんか違和感が…
納得できん

925:デフォルトの名無しさん
09/09/20 23:43:30
２つのクラス同士でクラスオブジェクト同士を相互参照したい場合、
class Topic:
　child = Reply

class Reply:
　parent = Topic

なんて書いてたら、当然２行目で未定義識別子の参照でエラーになる。
これって、２つの定義を相互参照なしに定義した後で、classmethodを明示的に呼び出して
動的に結びつけるしか方法がないよね？

用途としては自作の軽量ORMライブラリを作ってるところで、
オブジェクト化したテーブル同士の親子関係を表現しようとしている。
で、例えばTopicから連結されてるReplyのインスタンスが欲しいので何らかの形で事前に教えておく必要がある、と。

926:デフォルトの名無しさん
09/09/20 23:51:30
class Topic:
　　　　pass

class Reply:
　　　　pass

Topic.child = Reply
Reply.parent = Topic

927:デフォルトの名無しさん
09/09/21 00:01:17
>>924
それ、初期化じゃなくて代入だから・・・

928:デフォルトの名無しさん
09/09/21 00:38:33
？

929:デフォルトの名無しさん
09/09/21 01:38:05
>>924
の思考に違和感が

930:デフォルトの名無しさん
09/09/21 01:40:50
class Topic:
　children = []

class Reply:
　parent = Topic

Topic.children.append(Reply)

931:デフォルトの名無しさん
09/09/21 09:21:42
>>924
入門書嫁。

932:デフォルトの名無しさん
09/09/21 09:34:48
>>924は何に対して違和感を感じているんだろう
配列が伸び縮みすることになのか
要素の範囲を指定して代入することになのか
L[:] ってなんかきんもー、なのか

933:デフォルトの名無しさん
09/09/21 10:42:30
>>> l=[9,8,7,6]
>>> l
[9, 8, 7, 6] <- 普通
>>> l[1:]=[3,4,5]
>>> l
[9, 3, 4, 5] <- 普通
>>> l[1:]=[2,1]
>>> l
[9, 2, 1] <- きもい
>>> l[:]=0
Traceback (most recent call last):
　 File "<stdin>", line 1, in <module>
TypeError: can only assign an iterable <- 微妙
>>> l[:]=[0,0]
>>> l
[0, 0] <- きもい

934:デフォルトの名無しさん
09/09/21 10:47:29
[1:]=の結果に違和感覚えないのに[:]の結果に違和感覚える理由が解らん

935:デフォルトの名無しさん
09/09/21 11:08:09
>>933
スライスの代入で左辺と右辺のリストの要素数が
一致していなくても構わない（右辺にあわせて伸び縮みする）のが気持ち悪いってこと？
だったらリンクリストでも勉強すれば違和感なくなるんじゃないかね

936:デフォルトの名無しさん
09/09/21 13:53:54
>>934
>>> l[1:]=[2,1]
>>> l
[9, 2, 1] <- きもい

937:デフォルトの名無しさん
09/09/21 14:02:18
だから入門書読めよ低脳。

938:デフォルトの名無しさん
09/09/21 14:14:12
バカだなあ。

939:デフォルトの名無しさん
09/09/21 14:31:56
つーか、それがキモイならスライスの意味ないだろとｗ

940:デフォルトの名無しさん
09/09/21 17:05:35
>>> l[1:]=[3,4,5]
>>> l
[9, 3, 4, 5] <- 普通
>>> l[1:]=[2,1]
>>> l
[9, 2, 1] <- きもい

このきもいと普通の違いがわからん
要素が1個減ったらきもい？何か見落としてるんだろうか・・・

941:デフォルトの名無しさん
09/09/21 17:42:29
C言語の配列かなんかと勘違いしてるんじゃね？
抽象度の高い操作を理解できないとか

942:デフォルトの名無しさん
09/09/21 18:08:31
スライスの代入ってあんまりやんないからどうでもいいや

943:デフォルトの名無しさん
09/09/21 20:57:09
python の配列って中身はリストなんですか？

と思ったら
L=[]
で L に代入してるな orz

944:デフォルトの名無しさん
09/09/21 21:06:25
変数名がL,M,Nではじまる場合にはリストなんだよ。

945:デフォルトの名無しさん
09/09/21 21:12:52
>>941
あぁ。3要素のときはreplaceに見えるからきもくないのか
よくわかったありがとう

946:デフォルトの名無しさん
09/09/21 21:13:33
Pythonのお勉強 Part35
ｽﾚﾘﾝｸ(tech板)

947:デフォルトの名無しさん
09/09/21 21:30:13
>>943
質問の意味がよくわからないが、
Pythonのリストはメモリ上の連続領域を利用した配列型のリスト
(C++のstd::vectorやJavaのArrayListの類)

いわゆる連結リストではないので途中に挿入する操作には弱い。

948:デフォルトの名無しさん
09/09/21 23:45:44
>>942
直感的に思えないから、俺もあまり使わないな。
冗長でも、新しいリストを作ってしまうな

949:デフォルトの名無しさん
09/09/22 02:10:54
>>948

>>947 の言う通りなら新しく作りなおしてもそんなに速度は変わらなさそうですね

950:デフォルトの名無しさん
09/09/22 10:35:41
実装は連続メモリ型かも知れんが
表向きリストのような動作をするように設計されてんだろうな

951:デフォルトの名無しさん
09/09/23 12:59:51
from VideoCapture import Device

cam = Device()
cam.saveSnapshot('image.jpg')