Pythonのお勉強 Part3 ..
794:デフォルトの名無しさん
08/12/26 15:19:05
>>790
先を越されてしまったようだが……
コールバックとしては、↓のようにクラスのメソッドも普通に使えるよ。
import ctypes
BOOL = ctypes.c_int
HWND = ctypes.c_ulong
LPARAM = ctypes.c_ulong
EnumWindowsProc = ctypes.WINFUNCTYPE(BOOL, HWND, LPARAM)
user32 = ctypes.windll.user32
class Foo(object):
def __init__(self):
self.windows = []
def MyEnumWindowsProc(self, hwnd, lparam):
self.windows.append(hwnd)
return 1
def __call__(self):
user32.EnumWindows(EnumWindowsProc(self.MyEnumWindowsProc), 0)
return self.windows
for hwnd in Foo()(): print "%08X" % hwnd
795:デフォルトの名無しさん
08/12/26 15:33:10
>>793
Pythonは関数型言語じゃありませんよということを説明しただけだよ
Pythonに関数型言語になって欲しいとは一言も言ってない
マルチパラダイム言語の中で考えれば、Scalaあたりに比べれば
言語の記述力自体は別に平凡な部類でしょ、Pythonは
796:デフォルトの名無しさん
08/12/26 15:45:25
On Python
URLリンク(www.shido.info)
ython と Ruby は実はほとんど同じで、むきになるほどの差はないと思います。 (ただ、Python は Haskell などの最近の関数型言語の影響が強く見られ、 一方、Ruby は Smalltalk や Eiffel などのオブジェクト指向言語と Lisp の影響が見られます。)
797:デフォルトの名無しさん
08/12/26 15:49:34
>>796
URLリンク(d.hatena.ne.jp)
で叩かれてたサイトだな
798:デフォルトの名無しさん
08/12/26 15:54:24
>>797
せっかく有用な比較してるのに妙な叩きするなよ
zopeとダンジョの比較情報探すのもかなり苦労したんだから
799:デフォルトの名無しさん
08/12/26 15:59:59
有用な比較って……
Pythonでシークエンス型は参照渡しで他は値渡しって記述は俺も
ひどいと思ったけど
大嘘じゃん
800:デフォルトの名無しさん
08/12/26 16:05:05
そもそもPythonレベルで参照渡しなんて概念を持ち出す必要があるのか疑問
801:デフォルトの名無しさん
08/12/26 17:18:57
>>800
お前相当アホだろ?
802:デフォルトの名無しさん
08/12/26 17:22:40
すみませんが、質問です。
ジェネレータを通常のリストに変換する簡潔な方法は無いでしょうか?
ジェネレータが逐次返してくる値を全部まとめたリストを得たいのです。
803:デフォルトの名無しさん
08/12/26 17:40:37
>>802
[ e for e in G ]
804:デフォルトの名無しさん
08/12/26 17:40:42
list
805:デフォルトの名無しさん
08/12/26 17:54:45
>>804
おお、こんなクラスが。ありがとうございました。
> Help on class list in module __builtin__:
>
> class list(object)
> | list() -> new list
> | list(sequence) -> new list initialized from sequence's items
>>803
リスト内包表記もかなり簡潔ですね。
806:デフォルトの名無しさん
08/12/26 17:56:49
>>791
早速ありがとうございます!!
でも実行すると最後にエラー出てました
EnumWindowsCallback = CFUNCTYPE(c_int, c_int, c_int)
↓
EnumWindowsCallback = WINFUNCTYPE(c_int, c_int, c_int)
でエラー出なくなりました
>>794
きれいなコードですね
ありがとうございました!!
807:デフォルトの名無しさん
08/12/26 18:21:56
>>796
駄本の著者だな
808:デフォルトの名無しさん
08/12/26 18:54:21
景品表示法的にグレーな本書いた人ね
809:デフォルトの名無しさん
08/12/26 19:05:47
URLリンク(www.amazon.co.jp)
続編は内容的にガッカリらしい
810:デフォルトの名無しさん
08/12/26 21:15:32
恥ぱい
811:デフォルトの名無しさん
08/12/26 21:27:53
中身がハッカーズ大辞典やアンサイクロペディアみたいなノリだったら
あのタイトルでも許せたんだけどな。
812:デフォルトの名無しさん
08/12/27 05:52:00
イテレータから、n 個ずつとってまとめたタプルを
次々返すようなジェネレータって標準モジュール内にないですかね?
itertools 内を見回しても見当たらないんですけど・・・
結構使う機能なので、使うたびにジェネレータ定義するの面倒だし、
この機能だけのためにモジュール定義するのとかも面倒だし、
標準モジュール内であると楽なんですが・・・
813:デフォルトの名無しさん
08/12/27 06:03:34
あの、回答まだでしょうか?
814:デフォルトの名無しさん
08/12/27 08:06:33
正月休みです
815:デフォルトの名無しさん
08/12/27 10:03:05
from 俺のitertools import pair
def pair(iterable, count):
"""
>>> list(pair(range(10), 3))
[(0, 1, 2), (3, 4, 5), (6, 7, 8), (9,)]
"""
iterable = iter(iterable)
stop = False
while not stop:
y = ()
try:
for i in range(count):
y += (iterable.next(), )
except StopIteration:
stop = True
if y: yield y
816:デフォルトの名無しさん
08/12/27 10:46:00
>>812
> この機能だけのためにモジュール定義するのとかも面倒だし、
Pythonのモジュール作るのは別に面倒じゃないと思うんだが……
つーかPythonのスクリプトって特別な呪文を唱えずとも全部モジュールとして
使えるわけだし、せいぜい既存のモジュールとファイル名がかぶらないようにだけ
注意しとけばいい
PYTHONPATH, PYTHONSTARTUP, sitecustomize.pyなどの手段で
sys.pathに自分用スクリプトディレクトリを加えておくといいぞ
Pythonみたいにモジュールが使いやすい言語でコードの再利用を考えないのは損だ
817:デフォルトの名無しさん
08/12/27 11:47:56
>>815>>816
分かりました。
myitertools.py みたいなのを作ってやってみようと思います。
818:デフォルトの名無しさん
08/12/27 11:57:00
ちょっと違うけど短くかけるな
def pair(iterable, n):
return izip(*[iter(iterable)]*n)
819:デフォルトの名無しさん
08/12/27 11:58:45
うへ,tuple って immutable っていうから
+= みたいなのはなしかと思い込んでた…
820:デフォルトの名無しさん
08/12/27 12:25:32
a += b って a = a + b として処理されるんでないの
821:デフォルトの名無しさん
08/12/27 12:26:35
もちろんそうだよ。
822:デフォルトの名無しさん
08/12/27 12:27:53
>>820
__iadd__()がある場合は__iadd__()で処理される
無い場合は、__add()__を用いて処理される
immutableの場合は当然__iadd__()なんてものはないから
普通に__add()__を用いて新しいオブジェクトが作られる
823:822
08/12/27 12:28:50
なんだ__add()__ってw
まあ意味分かるよね、ごめん
824:デフォルトの名無しさん
08/12/27 21:48:30
>>> zip(*[iter(range(10))]*3)
[(0, 1, 2), (3, 4, 5), (6, 7, 8)]
>>> zip(*[iter(range(10))]*4)
[(0, 1, 2, 3), (4, 5, 6, 7)]
825:デフォルトの名無しさん
08/12/27 22:14:25
>>815 >>818 >>824
この場合は末尾の扱いってどうすべきなのかな
826:デフォルトの名無しさん
08/12/28 00:07:52
用途によって末尾が必要な場合・不要な場合があるけど、
tupleで返す場合の戻り値は >>824 のように固定長にすべきじゃないかな。
また、>>815は、while ループ一巡辺り最大で
tuple += tuple で count - 1個, (iterable.next(), ) で count 個の不要な一時tupleオブジェクトが作成される。
この場合の作業変数はlistを使う方がベター。
827:デフォルトの名無しさん
08/12/28 05:15:16
余りが出たら、最後をデフォルト値で埋めてみる
def padpairs(iterable, n, default=None):
x = chain(iter(iterable), repeat(default, n-1))
return pair(x, n)
# pair は >>818 の奴
>>> list(padpairs(range(10),3))
[(0, 1, 2), (3, 4, 5), (6, 7, 8), (9, None, None)]
>>> list(padpairs(range(10),4))
[(0, 1, 2, 3), (4, 5, 6, 7), (8, 9, None, None)]
828:デフォルトの名無しさん
08/12/28 10:12:17
2.6以上ならizip_longestが使える
829:デフォルトの名無しさん
08/12/28 10:32:42
>>827
GJ
830:デフォルトの名無しさん
08/12/28 15:09:27
>>828
2.5でもmap使えばいいだろ
831:デフォルトの名無しさん
08/12/28 15:35:12
愚直にitertools.isliceで。
import itertools
def pair(iterable, count):
it = iter(iterable)
while 1:
a = tuple(itertools.islice(it, count))
if not a:
break
yield a
print list(pair(range(10), 3))
832:デフォルトの名無しさん
08/12/28 16:46:42
俺も考えてみたけど、>>824のシンプルさには敵わないな
>>> import itertools
>>> make_taker = lambda xs, n: lambda: tuple(itertools.islice(xs, n))
>>> iter_take = lambda xs, n: iter(make_taker(iter(xs), n), ())
>>> list(iter_take(range(10), 3))
[(0, 1, 2), (3, 4, 5), (6, 7, 8), (9,)]
833:デフォルトの名無しさん
08/12/28 19:14:36
see also itertoolsのドキュメント内 izip と 例 の grouper関数
834:デフォルトの名無しさん
08/12/29 00:37:20
>>830
mapだとイテレータや巨大なリスト等を扱うとき困る。itertools.imapだと末尾の扱いが若干異なる。
3.0 のbuiltinのmap はitertools.imap相当なので、mapで長さの異なるリストを扱っている場合は3.0への移植の際に注意が必要。
例えば、下のコードは 2.x と 3.0 で結果が異なる。
>>> list(map(lambda *xs:xs, *[iter(range(10))]*3))
835:デフォルトの名無しさん
08/12/29 01:42:21
>>832
nが大きな数になる時を考慮するなら、こっち(islice)の方が効率良さそう。
元質問からは少し外れるけど、file-likeオブジェクトや文字列の場合。
try:
from io import StringIO
except ImportError:
from StringIO import StringIO
def split_nbyte(stream, n):
return iter(lambda :stream.read(n),"")
def split_nbyte_str(s, n):
return group_nbyte(StringIO(s), n)
836:デフォルトの名無しさん
08/12/29 08:17:15
ie = win32com.client.Dispatch('InternetExplorer.Application')
ie.Navigate('URLリンク(www.google.co.jp)')
ie.Visible = True
while ie.busy:
time.sleep(1)
q = ie.document.all('q')
q.Value = 'python'
btnG = ie.document.all('btnG')
btnG.click()
これでGoogleの検索が出来ることが分かったのですが
検索結果を取り出す方法が良く分かりません
どうすれば出来ますか
837:デフォルトの名無しさん
08/12/29 08:32:37
print ie.document.body.innerHTML
838:デフォルトの名無しさん
08/12/29 08:53:40
っつーか
urllib2 じゃいかんのか
なにがしたいのかによるが
839:デフォルトの名無しさん
08/12/29 09:06:23
エラーが出ます><
840:デフォルトの名無しさん
08/12/29 11:12:01
Python3.0なんですが、urllib2がインポートできないのでそうしました。
あきらかに日本語ドキュメントがおかしいです。存在しません。
841:デフォルトの名無しさん
08/12/29 11:14:54
>>840
py3k の使用はもうちょっと待ったほうがいいって。
842:デフォルトの名無しさん
08/12/29 11:18:50
今の日本語ドキュメントは2.5用
843:デフォルトの名無しさん
08/12/29 11:24:02
3.0ではurllib周り大刷新してたはず
844:デフォルトの名無しさん
08/12/29 12:00:25
こんなところで質問する人間が使うバージョンじゃない。> 3.0
845:デフォルトの名無しさん
08/12/29 12:16:30
正式リリースされているんだからもっとレスがついていいと思う
846:デフォルトの名無しさん
08/12/29 12:42:20
英語読めない奴は2.5系使うのがいいよ。
847:デフォルトの名無しさん
08/12/29 12:43:50
英語読めても各種ライブラリを自分で移植したりビルドする気のない奴は(ry
848:デフォルトの名無しさん
08/12/29 12:57:35
正式リリースされたからってすぐ飛びつくもんじゃない。
メーカー製品みたいに、ドキュメントからサポート体制からリリースに合わせて
全力で整えてるわけじゃないんだから。
849:デフォルトの名無しさん
08/12/29 12:59:05
3.0から入るのも良いけれど、その場合は日本語ドキュメントはアテにならないから
英語ドキュメント読まないと。
850:デフォルトの名無しさん
08/12/29 18:34:58
怒濤の勢いで止めとけレスがw
851:デフォルトの名無しさん
08/12/29 19:15:45
僕はパイソンを使う権利が無い、資格が無いという事ですね。
こんなだから日本のPythonユーザの数は少ないんじゃないでしょうか。
明らかにおかしい。
852:デフォルトの名無しさん
08/12/29 19:27:26
どのバージョンも好きに使う権利があるが、
2.5.2がふさわしい。むしろ2.5.2のThe King。
853:デフォルトの名無しさん
08/12/29 19:32:18
>>851
出たばかりだから枯れてないし、情報も出回ってないから、
古いの使っとけ、というアドバイスをそこまで曲解するほうがおかしい。
854:デフォルトの名無しさん
08/12/29 19:38:22
>>851は荒らしだろ、相手にするなよ。
でも>>851の親がイカれた奴なのは確かだ。
855:デフォルトの名無しさん
08/12/29 19:40:42
>>854
相手するなよ
856:デフォルトの名無しさん
08/12/29 19:47:43
ろくにwhat's newも読まずに最新のバージョンを使って、urllib2がインポートできない
からとwin32comを使い、3.0は止めとけばと言われれば僻み丸出しとか馬鹿なの?
857:デフォルトの名無しさん
08/12/29 20:31:39
まあそう煽るなよ
初心者ならドキュメントの類を隅々まで読んでいないのも
一番新しい正式リリース版をインストールするのも、別に不思議なことじゃない
>>851はいつもの釣りだろ
858:デフォルトの名無しさん
08/12/29 20:33:32
まあ普通にバカだわな
859:デフォルトの名無しさん
08/12/29 20:45:17
>>852
っ2.5.4
860:デフォルトの名無しさん
08/12/29 22:27:45
またruby厨の降臨かよ
861:デフォルトの名無しさん
08/12/29 22:47:04
>>847
Ruby使うのやめてPythonにしたのは
各種ライブラリがそろってて
Rubyみたく自分で移植しなくてもよかったから
いまさらPy3kでライブラリ移植する必要が出てくるなら
Ruby使ってた方がまし
862:デフォルトの名無しさん
08/12/29 22:48:08
マニュアルの類は読まないってのが世間一般の常識として浸透してるから
そう目ゴジラ立てて怒らんとってくれ。
863:デフォルトの名無しさん
08/12/29 22:48:56
アドバイスだよ
864:デフォルトの名無しさん
08/12/29 23:00:10
アドバンスなら大いに結構
865:デフォルトの名無しさん
08/12/29 23:00:48
なんかレベルというより年齢層が高くなってきたな。
866:デフォルトの名無しさん
08/12/29 23:06:28
>>861
ならRuby使ってればいいじゃない
誰も君に強制はせんよ
867:デフォルトの名無しさん
08/12/29 23:19:43
エンドユーザーならまだしも開発者がマニュアル読まないとかバカですって言ってるようなもんだろ
868:デフォルトの名無しさん
08/12/29 23:20:47
>>867
もう3.0の仕様を隅々まで把握してんのか?
すげーな
869:デフォルトの名無しさん
08/12/30 00:12:19
>>861
Pythonは、2.x の間は下位互換性を大事にバージョンアップしてきたし、
2.x -> 3.y は下位互換性失われるけど、 3.x -> 3.y はまた互換性をできるだけ
確保しながらバージョンアップしていく。
Rubyだと、1.8->1.9 でも、 1.9->2.0 でも、きっと互換性の問題出るよ。
870:デフォルトの名無しさん
08/12/30 00:28:41
>>868
差分があるしね
871:デフォルトの名無しさん
08/12/30 00:34:38
>>868
必要に応じてマニュアルを読む事とマニュアル全てを把握している事は別
872:デフォルトの名無しさん
08/12/30 01:06:39
>>869
1.8.6→1.8.7でも互換性の問題あるし、
1.8.6でも仕様を替えて互換性がなくなったこともあった。
873:デフォルトの名無しさん
08/12/30 01:35:53
Rubyの問題は仕様が明示されていないことだ。
互換性の問題があるのかどうかすら分からないのだ。
こんな言語を仕事に使おうと思う奴は馬鹿かアホかキチガイだと思う。
874:デフォルトの名無しさん
08/12/30 01:39:47
Python仕事に使ってんのか
いいな
875:デフォルトの名無しさん
08/12/30 01:45:02
3.0 始める人は、What's new, PEP3000 と 2to3 くらいは把握しておいた方がいいと思う。
ライブラリで移動したものも捕捉してくれる。>2to3
- from urllib2 import urlopen
+ from urllib.request import urlopen
ところで、googleでの検索なら API 使ったほうかいいんじゃないかな。
google 検索を urllib でやる場合、UserAgent 等を設定しないといけないので注意。
また、自前で検索結果をパースする場合 BeautifulSoup 使いたいなら 3.0 だとまだちょっと手間がかかる
(windowsユーザにとって)。先日のリリース で BeautifulSoup も 3.0 に対応したみたいだけど、
パッケージ内に diff や パッチを当てるto3.sh が含まれているだけなので、自分でパッチ当てないといけないみたいだし。
876:デフォルトの名無しさん
08/12/30 02:07:46
まあその辺は元からのPythonユーザや、このスレ見てる人にはわかってることでしょ
Pythonとやらを試してみっか、と考えた大量の新規ユーザが
地雷にはまってるだろうことは想像に難くないが
877:デフォルトの名無しさん
08/12/30 03:03:52
>>876
ライブラリが対応しているかどうかはプロジェクトのページを見れば書いて
あるし、まだほとんどのlinuxディストリビューションでは3.0は標準でイン
ストールされていない。その状況には同意しかねる。
それに公式のダウンロードページにもこう書いてある。
> Note that both Python 2.6 and 3.0 are considered stable production
> releases, but if you don't know which version to use, start with
> Python 2.6 since more existing third party software is compatible
> with Python 2 than Python 3 right now.
ここであえて3.0を選ぼうという初心者が大量にいるとは思えない。
878:デフォルトの名無しさん
08/12/30 03:11:25
そんなことはスルーor知らずに3.0選んでこそ真の初心者とも言えるがな
879:デフォルトの名無しさん
08/12/30 03:28:55
初心者ならLinux使ってないだろうし
良く知らない言語をちょっと試すかってときに
わざわざ英文なんて読まないよな
880:デフォルトの名無しさん
08/12/30 03:34:32
URLリンク(japanese.joelonsoftware.com)
881:デフォルトの名無しさん
08/12/30 04:10:14
日本語ドキュメント、書籍、等の外部のリソースの事も考えると
公式サイトの勧めているバージョンが、必ずしも全てのユーザに合ってるとは限らないってのが現状じゃない?
いくら互換性があるといっても、(2.x系)例えば windowsユーザだと、ライブラリのインストールで
ビルド済のインストーラが必要なユーザ層等もいるはずだし。
今は、若干 Python のリリースが先行してる時期だと思う。
早くどれかのバージョンに収束して欲しいという意味を込めても、
出来るだけ新しい安定版を勧めたいとこだけど...
その辺(これからどのバージョンを使うか)の認識って皆どうなんだろう?
882:デフォルトの名無しさん
08/12/30 04:16:00
とりあえず、自分の認識をまとめて書き出してみる。(突っ込み歓迎)
これからPythonを試してみる人
ライブラリ類が必要 -> 2.x
日本語ドキュメントも必要 -> 2.5
レンタルサーバで使いたい -> 2.4 が無難?
これから新規にライブラリを書く既存Pythonユーザ
2.xユーザを考慮するなら -> 2.6 ベースでコード書いて2to3
新規にアプリケーションを書く人
ライブラリが必要なら -> 2.x
過去の遺産なんていらない -> 3.0
こんなアドバイス必要ない
-> 複数バージョンをインストール済
883:デフォルトの名無しさん
08/12/30 04:39:04
>>866
国語力ないですねw
884:デフォルトの名無しさん
08/12/30 05:32:48
これからPythonを試してみる人 -> 3.x
ライブラリ類が必要 -> 2.6.x
日本語ドキュメントも必要 -> 2.6.x
レンタルサーバで使いたい -> 2.6.x
これから新規にライブラリを書く既存Pythonユーザ -> 3.x
2.xユーザを考慮するなら -> 2.6.x ベースでコード書いて2to3
新規にアプリケーションを書く人 -> 3.x
ライブラリが必要なら -> 2.6.x
こんなアドバイス必要ない -> どうせ読んでないだろうから何も言いません
885:デフォルトの名無しさん
08/12/30 05:44:29
いろいろ、ごにょごにょしようとすると、
ライブラリ便利だなぁ、、
886:デフォルトの名無しさん
08/12/30 06:06:17
ライブラリの力を自分の能力と勘違いしてしまいますよね
887:デフォルトの名無しさん
08/12/30 07:17:39
>>879
なら、本、買えよ
中央図書館で借りてこいや
888:デフォルトの名無しさん
08/12/30 07:29:43
いるいる
勘違いした香具師
889:デフォルトの名無しさん
08/12/30 07:39:06
>>879
> 初心者なら(略)読まないよな
帰国子女初心者の僕に対する挑戦と受け取りますた
890:デフォルトの名無しさん
08/12/30 07:57:41
BeautifulSoup Release 3.1.0 (2008/12/27)
2.4/3.0 のハイブリッド版。新しい機能の追加等はなし。3つの後方非互換が在り。
1. str()や__str__の振舞が変わる。-> バイト文字を得るにはencode()/unicode文字を得るには decode() を使う。
2. SGMLParserベースからHTMLParserベースに変更。(sgmllibが標準からなくなるため)
此れにより、壊れた HTML文書 を扱えなくなる。
将来のバージョンでは、速度と壊れたHTML文書の扱いのトレードオフで、パーサを選択できるようにする予定。
3. (Python3で) 属性中のエンティティの扱いで、パース時にunicode文字に変換されることがある。
例: <a href="URLリンク(crummy.com?sacré&bleu)"> -> Python 3 では é が "\xe9" に。
891:デフォルトの名無しさん
08/12/30 08:27:42
3.0対応版出すの早いな。GJ
892:デフォルトの名無しさん
08/12/30 08:33:57
ライブラリなかったら他の言語使うし
893:デフォルトの名無しさん
08/12/30 09:22:13
ライブラリ使わない開発なんてあるのか?
Hello Python!レベル?
894:デフォルトの名無しさん
08/12/30 12:01:18
帰国子女って変な用語だよな
帰国子士にすべき
895:デフォルトの名無しさん
08/12/30 13:11:55
谷底から這い上がってきた感じがする
896:デフォルトの名無しさん
08/12/30 17:20:59
僕も全然始めたばっかりの初心者だけど
3.0でUnicodeが云々で日本語の扱いがより簡単になった
(2系程複雑じゃない?)から3.0から始めたいなぁ、とか思ったよ。
897:デフォルトの名無しさん
08/12/30 17:29:39
今でもUnicodeEncode(Decode)Errorを見るとため息が出る。
898:デフォルトの名無しさん
08/12/30 17:37:04
UnicodeEncode(Decode)Error
慣れれば原因想像つくんだけど
途方に暮れてる人も多いんじゃないかな
899:デフォルトの名無しさん
08/12/30 17:42:28
初心者にもいろいろいるだろう
Perlから来た人
COBOLから来た人
FORTRANから来た人
とかの「他言語の経験のあるPython初心者」とか
Linux?何それおいしいの?な「Linux初心者&Python初心者」とか
プログラミング言語?何それおいしいの?っていうかWindowsって何?とか
900:デフォルトの名無しさん
08/12/30 18:38:37
>>896
>3.0でUnicodeが云々で日本語の扱いがより簡単になった
より簡単になった?
ご冗談はよしてください。
901:デフォルトの名無しさん
08/12/30 20:08:41
バイト列とユニコード文字列が別にあって
でも両方にほぼ同じメソッドがあって(encode, decodeまで)
でも中身は別物なので使い分けないといけない
という状況が解消されたんだから
「より簡単になった」と言っていいと思うよ
902:デフォルトの名無しさん
08/12/30 20:47:36
「マシになった」と言うべき
903:デフォルトの名無しさん
08/12/30 20:59:33
より良くなったと見るかより糞でなくなったかと見るか
904:デフォルトの名無しさん
08/12/30 21:08:13
文字列から正規表現にマッチする部分をすべて探して表示するにはどうすればよいでしょうか?
log: 文字列
regex: コンパイル済み正規表現
のとき
res = regex.search(log)
print res.group()
としたところ、最初にマッチしたもののみが返されるというところまではたどり着きました。
905:デフォルトの名無しさん
08/12/30 21:12:12
URLリンク(www.python.jp)
いやー、簡単になって本当〜〜〜に良かったよね!!
906:デフォルトの名無しさん
08/12/30 21:13:59
UnicodeEncodeError: 'cp932' codec can't encode character u'\xbb' in position 2091: illegal multibyte sequence
こんなエラーが出るんですけど原因はなんでしょう?
907:デフォルトの名無しさん
08/12/30 21:27:21
>>904
6.2. match() vs search()
match() 関数は、正規表現が先頭でマッチするかを調べるだけで、
search() は文字列の先へ進みながら、マッチする部分を探します。
この違いを覚えておくことは重要です。
match() は位置 0 でマッチした場合のみ報告してくれます。
もしマッチが位置 0 以外ならmatch() は報告しません。
>>> print re.match('super', 'superstition').span()
(0, 5)
>>> print re.match('super', 'insuperable')
None
反対に、search() は文字列を先へと探していき、最初に見付けたマッチを返します。
>>> print re.search('super', 'superstition').span()
(0, 5)
>>> print re.search('super', 'insuperable').span()
(2, 7)
ときどき、あなたは re.match() のみを使って、
正規表現の前に .* を付けておくという誘惑にかられるかも知れません。
この誘惑に打ち勝って、re.search() を使いましょう。
正規表現のコンパイラは、マッチ部分の探索を高速に行うために、
正規表現をそれなりに解析します。
そのような解析のひとつが、最初のマッチ文字が何であるか見付けることです。
たとえば Crow で始まるパターンは "C" で始まる文字列とマッチしなければいけません。
この解析により、マッチングエンジンは、文字列の中から最初の文字を素早く探索し、
見付かった場合だけ全体のマッチを試みるのです。
.* を付け加えると、この最適化ができないため、文字列の最後まで探索してから、
残りの正規表現のマッチ部分を探しに逆戻りすることが必要になるのです。
908:904
08/12/30 21:32:29
>>907
match でなくて search を使うところまではわかったのですが「次にマッチするもの」はどのように取得するのですか?
909:デフォルトの名無しさん
08/12/30 21:32:45
re.findall使えとかそういう話じゃないの?
910:デフォルトの名無しさん
08/12/30 21:38:59
>904
>>> import re
>>> l = 'hagefugahogemogepiyo'
>>> r = re.compile('ge', re.I)
>>> [m for m in r.findall(l)]
['ge', 'ge', 'ge']
911:デフォルトの名無しさん
08/12/30 21:40:00
python.jp の説明が糞な件
912:デフォルトの名無しさん
08/12/30 21:41:26
finditerの方が良いって話もあるけど実際どうなん?
913:デフォルトの名無しさん
08/12/30 21:41:42
>>904
findall
914:デフォルトの名無しさん
08/12/30 21:48:11
>>> r = re.compile('(a)(g)', re.I)
>>> [m for m in r.findall(l)]
[('a', 'g')]
>>> [m.group(0) for m in r.finditer(l)]
['ag']
>>> [m.group(1) for m in r.finditer(l)]
['a']
>>> [m.group(2) for m in r.finditer(l)]
['g']
915:デフォルトの名無しさん
08/12/30 21:50:11
>>910
[m for m in r.findall(l)]
やってることが意味不明なんだがwwwwww
916:デフォルトの名無しさん
08/12/30 21:51:42
>>915
[o for o in [n for n in [m for m in r.findall(l)]]]
917:デフォルトの名無しさん
08/12/30 21:53:08
>>> r=re.compile('(a)(o)', re.I)
>>> [m for m in r.findall(l)]
[]
>>> [m.group() for m in r.finditer(l)]
[]
>>> [m.group(0) for m in r.findall(l)]
[]
>>> [m.group(1) for m in r.finditer(l)]
[]
>>> [m.group(2) for m in r.finditer(l)]
[]
918:デフォルトの名無しさん
08/12/30 21:59:51
>915
おまえは黙ってろ
919:デフォルトの名無しさん
08/12/30 22:27:12
>>910
>>> [m for m in r.findall(l)]
['ge', 'ge', 'ge']
>>> r.findall(l)
['ge', 'ge', 'ge']
920:904
08/12/30 22:38:51
>>910 のとおりだとうまくいかず、マッチするべきものの部分文字列のタプルのリスト (で表現があってるかどうかわかりません、間違っていたらごめんなさい) が返されてしまいます。
カッコ () がついたものだとダメなのでしょうか?
使用している正規表現は、単純化すると
r'(ho|ge){2} [hoge] (ho[ge]){4}'
のような形をしています。
921:904
08/12/30 22:45:54
無理矢理、カッコを使わないような形にしたところ動きましたが、もとの正規表現のままで解決可能であればお願いします。
922:904
08/12/30 22:47:42
まだでしょうか
923:デフォルトの名無しさん
08/12/30 23:00:38
ん?
regexp = re.compile(r'(ho|ge){2} [hoge] (ho[ge]){4}')
[ m.group() for m in regexp.finditer('hoge h hoghoehoghoe') ]
でいいだろ
924:923
08/12/30 23:01:55
あ、finditerの引数は実際の入力を入れるようにしてね
925:904
08/12/30 23:28:49
>>923
成功しました。ありがとうございます。
※ >>922は偽者です
926:デフォルトの名無しさん
08/12/31 01:02:38
くそったれなHTMLはBeautifulSoupに食わせてから他のxmlライブラリに渡せばいいことに気づいた
927:デフォルトの名無しさん
08/12/31 02:05:15
pythonのwebフレームワークはキャッシュ生成して鯖に負担かけないとかまでやってくれるのかな
できないらword pressと組み合わせたほうがいいかとも思いはじめてるんだが
928:デフォルトの名無しさん
08/12/31 02:13:26
もしかしたらRuby使った方が効率がよいかもしれんが
929:デフォルトの名無しさん
08/12/31 02:56:04
>>927
WSGI対応フレームワークでは、それは Middleware の役割。
どのWSGI対応フレームワークからでも、プラグインのように、
必要に応じて CacheMiddleware等 を追加してサーバを構成する事が可能。(例: Pylons + Beaker)
930:デフォルトの名無しさん
08/12/31 06:49:39
>>927
Google App Engine はキャッシュ持ってますよ
有効期限も自分で設定出来る
931:デフォルトの名無しさん
08/12/31 09:52:29
RoRとかって以外と再利用性低いよな。
WSGIの世界になれると戻れない(www
932:デフォルトの名無しさん
08/12/31 10:14:12
>14
import urllib, urllib2, cookielib, time
req = urllib2.Request('URLリンク(pc11.2ch.net)', urllib.urlencode({
'bbs' : 'tech', 'key' : '1226830195', 'time' : int(time.time()),
'submit' : u'書き込み'.encode('sjis'), 'FROM' : 'fushianasan', 'mail' : 'sage',
'MESSAGE' : u'おっぱい'.encode('sjis'), 'suka' : 'pontan'}),
{'Referer' : 'URLリンク(pc11.2ch.net)'})
cj = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
res1 = opener.open(req)
if '<!-- 2ch_X:cookie -->' in res1.read():
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
res2 = opener.open(req)
933:デフォルトの名無しさん
08/12/31 10:16:56
おっぱい
934:fushianasan
08/12/31 13:13:38
おっぱい
935:デフォルトの名無しさん
08/12/31 13:48:31
おっぱい
936:fushianasan
08/12/31 15:35:55
ぱいぱん
937: 【1603円】 【大吉】
09/01/01 00:07:16
( ゚∀゚)o彡おっぱいそん! ( ゚∀゚)o彡おっぱいそん!
938: 【大吉】 【24円】
09/01/01 00:10:44
おっぱい
939: 【吉】
09/01/01 00:15:16
しねばいいよ
940: 【ぴょん吉】
09/01/01 00:56:07
あけおめー
941: 【1192円】 【大吉】
09/01/01 12:59:17
URLリンク(journal.mycom.co.jp)
942:デフォルトの名無しさん
09/01/01 13:04:43
相変わらずヌルいなあ>後藤とかいうひと
943:デフォルトの名無しさん
09/01/01 13:10:08
Unix系なんでもライターだからこんなもんだろ。
例えば安藤さんのプロセッサ記事みたいなクオリティを期待しちゃいかん。
944:デフォルトの名無しさん
09/01/01 13:34:51
URLリンク(gihyo.jp)
945: 【1499円】
09/01/01 14:19:24
age
946: 【小吉】
09/01/01 14:19:53
>>941 >>944
GJ!!
947:デフォルトの名無しさん
09/01/01 16:54:40
>941
●テキストからバイナリデータへの変換: str.encode() または str(b, encoding=...)
●バイナリデータからテキストへの変換: bytes.decode() または bytes(s, encoding=...)
これは「または」の部分が逆ですか?
948:デフォルトの名無しさん
09/01/01 17:00:17
自分で調べろ
949:デフォルトの名無しさん
09/01/01 17:03:32
As the str and bytes types cannot be mixed,
you must always explicitly convert between them.
Use str.encode() to go from str to bytes,
and bytes.decode() to go from bytes to str.
You can also use bytes(s, encoding=...)
and str(b, encoding=...), respectively.
950:デフォルトの名無しさん
09/01/01 17:05:07
やっぱり誤訳ですよね
951:デフォルトの名無しさん
09/01/01 18:09:37
きっと気の利いた編集者がしょうがないなぁって直してくれたんだよ
952:デフォルトの名無しさん
09/01/01 20:09:25
Unix系なんでもライターだからこんなもんだろ。
元日だけにおめでたいことだ。
953:デフォルトの名無しさん
09/01/01 20:28:00
>>944
このページってリンク0000だけ?
何も出てこないんだけど
954:デフォルトの名無しさん
09/01/01 21:39:55
%愛してたのになくなるのか・・・
955:デフォルトの名無しさん
09/01/01 21:59:52
>>954
剰余算なくなるってこと??
956:デフォルトの名無しさん
09/01/01 22:27:06
print JK
957:デフォルトの名無しさん
09/01/01 23:03:27
>>954
print.format になるのか
958:デフォルトの名無しさん
09/01/01 23:38:33
>>955
文字列の % が format メソッドにかわるだけで
数字の剰余はそのまま残る
959:デフォルトの名無しさん
09/01/01 23:42:27
3.0 の時点で既にobsolete
URLリンク(docs.python.org)
960:デフォルトの名無しさん
09/01/01 23:45:34
Pythonのお勉強 Part31
スレリンク(tech板)
961:デフォルトの名無しさん
09/01/01 23:46:03
>953
連載って書いてあるから、しばらくしたら追加されるんだろ
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5100日前に更新/206 KB
担当:undef