10/03/13 16:59:28
Pythonオフィシャルサイト
URLﾘﾝｸ(www.python.org)
日本Pythonユーザ会
URLﾘﾝｸ(www.python.jp)
まとめWiki
URLﾘﾝｸ(python.rdy.jp)
関連スレ
URLﾘﾝｸ(find.2ch.net)
前スレ
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
10/03/13 17:00:43
参考図書
URLﾘﾝｸ(python.rdy.jp)
3:デフォルトの名無しさん
10/03/13 17:08:06
●標準ライブラリミニツアー
URLﾘﾝｸ(www.python.jp)
●レシピ集
URLﾘﾝｸ(code.activestate.com)
●exeファイルの作り方
URLﾘﾝｸ(www.py2exe.org)
●GUI ライブラリ
Tkinter
URLﾘﾝｸ(ja.wikipedia.org)
PyQt4
URLﾘﾝｸ(www.riverbankcomputing.co.uk)
wxPython
URLﾘﾝｸ(www.wxpython.org)
4:デフォルトの名無しさん
10/03/13 17:09:38
●参考サイト
URLﾘﾝｸ(python.rdy.jp)
●Web フレームワーク等
Pylons
URLﾘﾝｸ(pylonshq.com)
django
URLﾘﾝｸ(www.djangoproject.com)
TurboGears
URLﾘﾝｸ(www.turbogears.org)
Plone
URLﾘﾝｸ(plone.org)
Zope
URLﾘﾝｸ(www.zope.org)
web.py
URLﾘﾝｸ(webpy.org)
werkzeug
URLﾘﾝｸ(dev.pocoo.org)
Kay
URLﾘﾝｸ(code.google.com)
Paste
URLﾘﾝｸ(pythonpaste.org)
wsgi
URLﾘﾝｸ(www.python.org)
5:デフォルトの名無しさん
10/03/13 17:25:36
CherryPy
URLﾘﾝｸ(www.cherrypy.org)
6:デフォルトの名無しさん
10/03/13 17:28:55
KanPy
URLﾘﾝｸ(upload.wikimedia.org)
7:デフォルトの名無しさん
10/03/13 18:55:28
pass
8:デフォルトの名無しさん
10/03/13 19:54:17
実装各種
Python2.6 （C言語実装、よく分からない人はこれ）
URLﾘﾝｸ(www.python.org)
Python3.1 （C言語実装、バージョンの違いを理解している人用）
URLﾘﾝｸ(www.python.org)
Jython2.5 （Java実装）
URLﾘﾝｸ(www.jython.org)
IronPython2.6 （C#（.NET）実装）
URLﾘﾝｸ(www.codeplex.com)
9:デフォルトの名無しさん
10/03/13 20:05:56
cと連携するときってctypesとCythonどっちがいい?
10:デフォルトの名無しさん
10/03/13 20:28:59
swig
11:デフォルトの名無しさん
10/03/13 21:06:22
>>1-8
乙
12:デフォルトの名無しさん
10/03/13 21:11:38
cyclone
13:デフォルトの名無しさん
10/03/13 23:40:25
Bython
14:デフォルトの名無しさん
10/03/14 00:58:30
C#
15:デフォルトの名無しさん
10/03/14 01:21:30
今日はπthonの日
16:デフォルトの名無しさん
10/03/14 01:47:56
前スレRとの比較にはすごい興味あり
17:デフォルトの名無しさん
10/03/14 01:59:26
3.14 15926
18:デフォルトの名無しさん
10/03/14 04:03:29
pypy 1.2 release
19:デフォルトの名無しさん
10/03/14 05:13:24
974 デフォルトの名無しさん [sage] 2010/03/13(土) 11:04:22 ID: Be:
PyPy Status Blog: Introducing the PyPy 1.2 release
URLﾘﾝｸ(morepypy.blogspot.com)
パイパイ！
20:デフォルトの名無しさん
10/03/14 07:39:11
>>1
おっぱい
21:デフォルトの名無しさん
10/03/14 07:43:10
pypyってなんです？
22:デフォルトの名無しさん
10/03/14 10:58:28
Python 2.5.4 です
>>> '1.5'.isdigit()
False
>>> '15'.isdigit()
True
>>> '-15'.isdigit()
False
1.5 は仕方ないとして
-15 は digit ではないのでしょうか？
あと -15 でも True になるような判定方法でふさわしいものがあったら教えてください orz
23:デフォルトの名無しさん
10/03/14 11:26:04
>>21
Pythonで書かれたPythonの処理系。詳しくは以下。
URLﾘﾝｸ(codespeak.net)
24:デフォルトの名無しさん
10/03/14 11:32:46
>>22
isdigitは0123456789かどうかを調べるもので+,-,.は偽
数値かどうかは int("-15"), float("1.5") して ValueError の例外がでたら偽
25:デフォルトの名無しさん
10/03/14 11:34:25
C#最高って何故かここでよく見るが
RUBYならともかくC＃はPYTHONが対抗言語と言う位置づけと感じているのか？
26:デフォルトの名無しさん
10/03/14 11:35:07
>>22
いいことを教えてやろう
'+15'.isdigit() も False だ
27:デフォルトの名無しさん
10/03/14 11:39:10
>>25
ネタにマジレスかこいい
28:デフォルトの名無しさん
10/03/14 11:39:38
int('- 5') は OK なのに float('- 5') はエラーになるんだよね...
29:デフォルトの名無しさん
10/03/14 11:43:43
節操ないなw
30:デフォルトの名無しさん
10/03/14 11:59:33
>>27
マヂレスつか素朴な疑問なんだが
31:デフォルトの名無しさん
10/03/14 12:20:47
>>30
スレ立てるまでもない質問スレで Python を猛烈プッシュしてる人が居たから
呼び込んじゃったんだろう
32:デフォルトの名無しさん
10/03/14 12:22:59
ハッカーがプッシュしてるんだから間違いない
33:デフォルトの名無しさん
10/03/14 12:32:06
>>24
いちいち実行してみて例外出たらやり直しとか
Java みたいで格好悪くて納得できません
int('hoge', default=0) とか
int('fuga', errors='ignore') とか
なんで標準で無いんですか？
34:デフォルトの名無しさん
10/03/14 12:33:14
一生C#でTryParseしてればいいよ
35:デフォルトの名無しさん
10/03/14 12:36:02
そんなアホなコード誰も書かないから大丈夫だよ
36:デフォルトの名無しさん
10/03/14 12:40:08
>>30
コンパイルが必要な時点で、普通は比較対象から外れるよね
個人的にはREPLが無いのが決定的
MonoにはREPLあるみたいだけど
サーバ側での運用ってことであれば、対抗馬になるのかな？
string.formatの書式でC#をパクっちゃってるのも
C#厨を勢いづけてるのかもしれない
>>16
俺も興味あるなぁ
Rは全然使った事ないけど
Python (x, y)よりも優れた適用領域があるなら試してみたい
37:デフォルトの名無しさん
10/03/14 13:04:47
Pythonと比較するならF#だろうな
こっちはスクリプトだし.NET使えるし
38:デフォルトの名無しさん
10/03/14 13:20:59
F#スクリプトはいいね
あれがどのWindowsでもデフォで動くようになって
LL標準添付のライブラリを備えればいうことなし
39:デフォルトの名無しさん
10/03/14 13:32:34
つまりF#最高
40:デフォルトの名無しさん
10/03/14 13:37:06
逝ってよし
41:デフォルトの名無しさん
10/03/14 13:44:54
>>33
それはPythonが実用的な言語ではないから
実用性が欲しいのならF#をお薦めする
42:デフォルトの名無しさん
10/03/14 13:47:50
pass
43:デフォルトの名無しさん
10/03/14 14:07:20
>>28
両方エラーになるけど？
44:デフォルトの名無しさん
10/03/14 14:14:44
>>33
default=0 は判るけど、 errors='ignore' したらその関数の結果はどうなるの？
「実行して例外出たら」というのは、基本的にそういうポリシーでやってる。
なんでそんなポリシーなのかというと、
1. 先行チェック関数と実行関数の二つが必要になると、それだけ要素が増える
2. 先行チェックの関数を用意しても、実行用関数でチェックが不要になるわけではない。
3. 先行チェックだけが必要になる場合はあんまりない。
if int.tryparse(s):
x = int(s)
else:
x = 0
と書くのと、
try:
x = int(s)
except ValueError:
x = 0
と書くのと比べて、別に格好悪い事なんてなんにもないし。
45:デフォルトの名無しさん
10/03/14 14:25:47
x = int(s) if int.tryparse(s) else 0
46:デフォルトの名無しさん
10/03/14 14:38:01
>>45
tryparseなのに真偽しか返さないのはおかしくないか
47:デフォルトの名無しさん
10/03/14 14:40:54
>>44だった...
48:デフォルトの名無しさん
10/03/14 14:42:25
>>45
確かに、3項演算子が使えるのは便利だね。
でも、そのためだけに int.tryparse() を実装するのはやり過ぎ。
try文も3項演算子作ろうよっていう話が少し前に Python-dev や Python-idea で
流れたけど、例外のタイプを複数利用したい場合とか、汎用的に使える物を
きれいな構文にするのが難しくてまとまらなかった模様。
複数の文字列に対して繰り返し実行する必要がある場合は、その場合に応じて
関数作れば良いしね。手軽に関数を作れるのがPythonの良いところなんだから。
def toint(s, default=0): try: return int(s) except Exception: return default
x = toint(a)
y = toint(b, 1)
z = toint(c)
49:デフォルトの名無しさん
10/03/14 14:43:58
>>47
あー、名前をC#から拝借したんだけど、checkparsable()の方が好み？
真偽を返すのは、
if int.tryparse("0")
が偽にならないため。
50:デフォルトの名無しさん
10/03/14 14:46:57
>>48
ありがとうございました
51:48
10/03/14 14:54:08
あー、 try-except の部分、一行じゃ書けなかった。3行必要だ。
def toint(s, default=0):
try: return int(s)
except Exception: return default
52:デフォルトの名無しさん
10/03/14 14:55:36
>>43
Python3.1だとintの方もエラーになるけど、2.6だとならない
53:デフォルトの名無しさん
10/03/14 15:10:11
>>48
またコンビニ野郎かよ
そういう奴が居るからPythonは低速って言われるんだよ
54:デフォルトの名無しさん
10/03/14 15:11:09
そろそろ2.6にアップグレードしてもよかと？
55:デフォルトの名無しさん
10/03/14 15:15:50
せんとすはいつまで2.4なのかねぇ
56:デフォルトの名無しさん
10/03/14 15:17:48
>>53
こーゆー作業をしている部分はユーザーの入力チェックとか
設定ファイルの読み込みとかボトルネックじゃない事がほとんどだから
実行時間を気にする必要ないよね？
Pythonは低速とか、誰が非難してるの？
速度が必要な部分は拡張モジュール書けばいいんだし、
ボトルネック以外の部分が多少遅くても問題ない。
57:デフォルトの名無しさん
10/03/14 15:20:36
話は変わるけど、Pythonはほんとに低速
58:デフォルトの名無しさん
10/03/14 15:22:19
>>56
>速度が必要な部分は拡張モジュール書けばいいんだし、
>ボトルネック以外の部分が多少遅くても問題ない。
今時は動的言語も仮想マシンと実行時コンパイルが当たり前になって来たからな。
メソッド呼び出しとか真偽判定みたいな内部機能は拡張じゃどうしようもないし。
59:デフォルトの名無しさん
10/03/14 15:48:45
まだやってたのか
60:デフォルトの名無しさん
10/03/14 19:18:59
せんとすは2.6にアップグレードしてもよか
61:デフォルトの名無しさん
10/03/14 19:43:03
する意味ないからしないんだろう。
必要なら/usr/localに入れればいい。
62:デフォルトの名無しさん
10/03/14 20:23:14
CentOS の新しいメジャーバージョンが早く出てくれないと、いろんな主要ライブラリで
Python 2.4 のサポートを切る動きが出てこない。
有名なライブラリにテスト済みのパッチを送るためにローカルにPython 2.4, 2.5, 2.6, 3.1,
trunk, py3k を全部入れるのは面倒だ。
63:デフォルトの名無しさん
10/03/14 21:06:50
OSの根幹にかかわる部分をpythonで書くのは不安だ
perlじゃなぜダメなんだ
64:デフォルトの名無しさん
10/03/14 21:12:34
>>63
なぜPythonだと不安なんだ？
65:デフォルトの名無しさん
10/03/14 21:16:22
はっきり言って根幹じゃないほうが好きに弄れて気楽だな
66:デフォルトの名無しさん
10/03/14 22:27:20
CentOSはRHELクローンなので
RHELがPythonのバージョンを変えない限り変わらない
んで、そのRHELの実験的な実装の意味合いを持つFedoraでは
Python 2.6に移行済みでPython 3.xも同時にインストール可能となっている
なんで、RHEL6が登場するまで待てば、自然とPython 2.6になる
>>65
RedHat系はyumも含めてPythonがシステムツールに入り込んでるから
確かに、気軽に/usr配下にライブラリとか入れれないよね
まぁ、61の言うとおり『入れんな』ってことなんだろうけど
67:デフォルトの名無しさん
10/03/14 22:51:22
OSの根幹にかかわる部分をperlで書くのは不安だ
Rudyじゃなぜダメなんだ
68:デフォルトの名無しさん
10/03/14 22:56:01
virtualenvがあるから /usr/lib/python2.4 以下にライブラリをインストールなんて
必要ないし、新しいPythonを使いたかったら /usr/local/python2.6 にでも
インストールすればいい。
69:デフォルトの名無しさん
10/03/14 23:04:22
windows使えば解決
70:デフォルトの名無しさん
10/03/14 23:38:12
>16
前スレ 999 だけどリロードしないで激しく時差ぼけレスしちまったぃ
まあゆるーく続けますか(matplotlibスレの方がいいかも?)。
numpy,R,matlab等のそれぞれの比較早見表見つけた
(使い分ける人向け? っぽいので普通はあまり意味がないかも)
URLﾘﾝｸ(mathesaurus.sourceforge.net)
ぐぐって遭遇した1,2年前の話題
Python+Scipy+Matplotlib vs Matlab?
URLﾘﾝｸ(news.ycombinator.com)
71:デフォルトの名無しさん
10/03/14 23:38:54
文句あるなら根幹はCで書け
72:デフォルトの名無しさん
10/03/14 23:44:21
C は良い言語だよな。メモリ空間の隅々まで自由自在にアクセス出来るし。
73:デフォルトの名無しさん
10/03/14 23:47:10
逆に言うとCPUやレジスタは隠蔽してるので、Cで手に入る自由はメモリだけだな
結局現存するほとんどのOSの機能がCによって提供されてるってのが
Cの力だと思っている
74:デフォルトの名無しさん
10/03/14 23:56:43
もうわけワカメｗ
75:デフォルトの名無しさん
10/03/15 00:44:09
73ｗｗｗ
76:デフォルトの名無しさん
10/03/15 01:04:47
アセンブラが無いと話にならんな
77:デフォルトの名無しさん
10/03/15 04:56:14
テカテカ
78:デフォルトの名無しさん
10/03/15 05:21:04
まだやってたのか
79:デフォルトの名無しさん
10/03/15 20:26:41
例外処理ってのは、通常の処理手順とは異なる手順で処理するときに使うもんだよ。
引数がintの時も同じように計算して返すのに、なんでわざわざ例外処理でやるんだ。
普通の条件分岐で十分だろ。
80:デフォルトの名無しさん
10/03/15 21:04:47
まだやってたのか
81:デフォルトの名無しさん
10/03/15 21:11:20
Ruby スレで GUI が無いって騒いでるな
82:デフォルトの名無しさん
10/03/15 21:14:12
Python は wxPython の日本語の紹介がけっこうあるからなぁ。
83:デフォルトの名無しさん
10/03/15 21:38:27
wxPythonも2~3年くらい前はあまり見なかった
wxRubyは当時も今もあまり見ない
wxPythonの利用者の方が増えてるってことだよね
84:デフォルトの名無しさん
10/03/15 21:45:19
>>79
じゃあ、int('fdasl')と入力したときに、どういう風に返せば満足なの？
0返すなんて糞仕様は勘弁だからな。
85:デフォルトの名無しさん
10/03/15 22:12:26
def parseInt(s, default=None):
try:
return int(s)
except ValueError:
return default
みたいなのをたぶん前スレで誰かが言ってた
いづれにしても、自分で関数作ればよかろう
86:デフォルトの名無しさん
10/03/15 22:21:36
>>79
「例外は本当に例外的な場合にだけ使う」って、誰が言い出したのか知らないけど、
真っ赤なウソだよ。
例えば、ファイルを開くときに、ファイルが存在しなかったら IOError を出すけど、
開こうとする前に os.path.exists(filename) して存在を確認してもパーミッション等の
条件で開けないかもしれない、HDDがリードエラーを出すかもしれない、
チェックしたときはあったファイルが開こうとしたときに絶妙なタイミングで消えるかも
しれない、etc... で、事前チェックしても例外処理は外せない。なら、事前チェックと
例外チェック両方するより例外だけチェックする方が合理的。
特にPythonは、 for i in x: でも中で StopIteration 例外が飛んでるくらい、例外を
気軽に使う言語。
87:デフォルトの名無しさん
10/03/15 22:23:46
parseInt('0', 0)とか考えるとやっぱいらないかな
ってこの話題前にもあったね
Pythonのお勉強 Part35
ｽﾚﾘﾝｸ(tech板:395番)
88:デフォルトの名無しさん
10/03/15 22:32:49
>>86
エラーは全部例外でいいと思うんだよな
89:デフォルトの名無しさん
10/03/15 23:03:32
発生した例外を処理しないと必ず止まるってのは本当にありがたい
たまにCで書くとつくづく思う
90:デフォルトの名無しさん
10/03/16 00:36:29
try:
raise SyntaxError()
except SyntaxError:
print 'foo'
は期待通りに動作するのに、
try:
@ # <- syntax error
except SyntaxError:
print 'foo'
は動作しないんだなぁ。。
文法ミスがあった時点でそれ以降のスクリプトの内容の解釈は不可能だから当然なんだけど、なんか気持ち悪い。
91:デフォルトの名無しさん
10/03/16 00:45:51
print "hello"
@ # <- syntax error
これでhelloと表示されないのが気持ち悪いか?
92:デフォルトの名無しさん
10/03/16 02:30:59
多重ループを抜けるのに例外を使うのはどう？
93:デフォルトの名無しさん
10/03/16 02:35:50
ええでしょう
94:デフォルトの名無しさん
10/03/16 09:13:41
ええー
95:デフォルトの名無しさん
10/03/16 10:28:35
>>91
後ろでもそうなるのか。ほう。
syntax errorで動かないことはいいのだが、ユーザがSyntaxErrorをraiseできるのはどういう解釈なんだ？
96:デフォルトの名無しさん
10/03/16 10:32:23
>>95
「普通はユーザーが使う物じゃないから」なんて理由で、一部の例外オブジェクトを
catchできるけどraiseできないみたいなヘンな制限を付けてないだけだろうな。
raise KeyboardInterrupt だろうがなんだろうができるけど、普通はしない。
普通じゃない場合としては、プラグインシステムのあるアプリで、プラグインに
SyntaxErrorが起こるようなスクリプトをぶち込まれた場合をテストするために
あえてraiseするとかかなぁ。
97:デフォルトの名無しさん
10/03/16 10:55:51
>>90
「気持ち悪い」理由が俺にはさっぱりわからん
単に、エラーを含む可能性のあるPythonコードを実行時に解釈したいのなら
eval・compile系が使えるけど
>>92
多重ループどころか、列挙の停止はいつもStopIteration例外じゃないか
98:デフォルトの名無しさん
10/03/16 11:34:51
>>97
こういうことだろ。
class TajuuloopNukeru(Exception):
pass
try:
for i in someiter:
for j in someiter2:
if somecond:
raise TajuuloopNukeru # ここで一気にループを抜けるために例外を投げる
except TajuuloopNukeru:
pass
99:デフォルトの名無しさん
10/03/16 11:39:59
>>98
いや文意は分かってるよ
別に多重じゃなくてもどうせ列挙の脱出にはいつもStopIterationが使われてるんだから
好きにすれば？ってこと
100:デフォルトの名無しさん
10/03/16 11:48:04
例外はgotoの代わりに仕えって死んだじいちゃんが言ってた
101:デフォルトの名無しさん
10/03/16 12:15:10
イテレータの中で要素を動的にパースするときとか
自分用の小さいスクリプトだったら例外で抜けちゃうな
まあ、先にリスト作っとけって話なんだけど、楽なんで
102:デフォルトの名無しさん
10/03/16 12:35:31
先にリストを作ると、長大に要素を含む可能性のあるイテレータの処理が重くなったりすると思うんだ。
103:デフォルトの名無しさん
10/03/16 13:11:30
多重ループならそれこそジェネレータ使えよ
104:デフォルトの名無しさん
10/03/16 13:14:06
と言ってはみたがイテレータの中でraise StopIteration使っても同じことだな
よく読んでなかった
105:デフォルトの名無しさん
10/03/16 17:23:38
例外やgotoはpythonに限った話じゃないと思うんだが
その辺現状のマジョリティとしてはどういう見解なの？
なんか昔はgotoに拒絶反応示す人がいたように思うんだが
106:デフォルトの名無しさん
10/03/16 17:29:20
It is Easier to Ask for Forgiveness than Permission.
107:デフォルトの名無しさん
10/03/16 21:34:05
intのparseの例は、.NETのNullable型や関数型のOption型みたいなものがあれば
それで返せば、という気がしなくもない
例外やgoto云々は完全に言語によるのでは
少なくとも非常に手続き的だとは言える
C++界隈だと、別の理由で例外を過度に多用するなというコンセンサスがある気がする
108:デフォルトの名無しさん
10/03/16 23:26:33
辞書のgetにもdefaultがあるんだからデフォルト値指定ができてもいいと思うけどなー
あとoption型なんかは動的型ならNone返せばいいだけなので問題はそこじゃないと思う
109:デフォルトの名無しさん
10/03/17 00:02:56
>>108
int() に default をつけてしまうと、こんどは例外を投げられなくなってしまう。
例えば、defaultのデフォルト値がNoneだとすると、「int()に変換できるハズ」と
思い込んで返り値チェックを省略すると数値オブジェクトを期待している場所に
Noneが入った状態で、その後のどこかでエラーが起こるか何かを壊してしまう。
例外なら、「ハズ」の思い込みと違うことが起こっても帯域脱出してくれるので、
「ハズ」の部分でチェックを省略できる。
辞書に [] と .get() があるように、int()と別の関数として用意するのはアリ。
アリだから、 >>51みたいな関数を用意すれば良い。
組み込み名前空間を汚してまで組み込む必要が認められなかったので
組み込み関数にはなって無いだけ。
110:デフォルトの名無しさん
10/03/17 00:12:17
int(hoge, default=None) ができれば・・・
try:
fuga = int(hoge)
catch:
～～
が
fuga = int(hoge, default=None)
if fuga is None:
～～
3行になる！
ああ、石を投げないで！
111:デフォルトの名無しさん
10/03/17 00:34:46
じゃなくて、
try:
fuga = int(hoge)
catch:
fuga = 0
を考えてる時に例外使うのは素直じゃないだろということだろ
112:デフォルトの名無しさん
10/03/17 00:37:42
一瞬pythonスレじゃないのかとおもった
113:デフォルトの名無しさん
10/03/17 00:42:44
>>110
単にデフォルトで潰したいときも、パース不能のときも、それで済むなあ
まあこういうのはユーティリティ関数を自分で書けば事足りる程度の話ではあるが
114:デフォルトの名無しさん
10/03/17 00:45:42
>>111
それが素直じゃないと思うなら、まずその幻想を打ち壊す！
いや、「素直じゃない」なんてなんの根拠もない個人的感想は
全く気にしない言語だから。
例外投げる方がシンプルで、例外投げない方を別に用意しても
大して利益がないのであれば、例外なげない関数なんて用意しないよ。
>>110
int() はただの関数じゃなくて型だから、Noneを返すなんて仕様は有り得ない。
default を追加するなら int と別の関数を用意する必要がある。
でも、組み込み関数をその程度の要望では増やさない。
115:デフォルトの名無しさん
10/03/17 00:47:45
>>113
だから、>>109で言っているように、
fuga = int(hoge)
の一行が
fuga = int(hoge, default=None)
if fuga is None:
raise ValueError("hoge is not integer")
の3行に増えるんだって。
116:デフォルトの名無しさん
10/03/17 00:55:44
default の初期値は「未指定」でいいじゃない。
PyArg_ParseTupleAndKeywords()の書き方次第でNoneではない「未指定」のデフォルトにできるじゃんね。
int('abc') → ValurError
int('abc', 16) → 2748
int('abc', default=None) → None
117:デフォルトの名無しさん
10/03/17 01:13:30
>>116
「未指定」なんてオブジェクトはない
あと、>>114で言っているように int() が None を返しちゃダメ。
intかintと上位互換のlongを返さないと。
118:デフォルトの名無しさん
10/03/17 01:22:55
>>117
そういうオブジェクトはないけど、
def to_int(val, **kwargs):
if 'default' in kwargs:
pass
みたいな処理はできるってことを言いたいんじゃないかなぁ。
intがint以外のインスタンス返す仕様になってほしいとはまったくもって思わんけど。
119:デフォルトの名無しさん
10/03/17 01:34:12
ビルドインを増やすのが嫌なら
int.parse(string)ってスタティックメソッドを作ればいいんじゃないかな
120:デフォルトの名無しさん
10/03/17 01:47:14
>>117
それだと、今度は (val [, base [, default]]) という順序引数が使えなくなるね。
intが例外を投げる関数としてあるんだから、int以外の関数を使うなら
defaultは普通にNoneがデフォルト値の引数で良いんだよ。
問題は、大して利点無くビルトインを増やすこと。
>>119
うん、どうしてもdefaultが欲しいなら、それが一番Pythonicだね。
残る問題は、今のところ組み込み型にはstaticmethodが無いという事だけだ。
int.parseのためだけに組み込み型のstaticmethodを用意するのはやっぱり
無いだろうけど、他にも組み込み型staticmethodの要求が増えてきたら
ついでに int.parse が入るかも。
121:デフォルトの名無しさん
10/03/17 06:21:49
def int(s, exception=True, default=0):
みたいに定義しといて
exception=False
で使ったときだけdefaultを返せば良いと思う
122:デフォルトの名無しさん
10/03/17 09:33:17
型の変換はバリデータとかでさっくりやるんじゃねえの？
typeにstaticmethod追加するとかバカか？
123:デフォルトの名無しさん
10/03/17 10:18:34
>>122
えっ
124:デフォルトの名無しさん
10/03/17 10:24:44
>>122
元の要求は明らかに
unicode(s, 'utf-8', errors='ignore')
あたりからの類推だろうし、別にそんなに変な話じゃないと思うが
125:デフォルトの名無しさん
10/03/17 10:32:41
別ディレクトリにある.pyファイルをimportしたい時って、sys.pathを直接いじるのが一般的なの？
126:デフォルトの名無しさん
10/03/17 10:38:56
メインプログラムのサブディレクトリに配置すれば良いじゃん
127:デフォルトの名無しさん
10/03/17 11:03:58
__import__() を使おう
128:デフォルトの名無しさん
10/03/17 12:36:00
>>124
たしかにunicodeはencodingやerrrosを指定できるけど戻り値は必ずunicode型だろ
int(hoge, default=None)みたいにint以外返せるのはおかしい
129:デフォルトの名無しさん
10/03/17 12:36:50
おいおい、まだやってたのか
130:デフォルトの名無しさん
10/03/17 12:41:03
unicode のつもりが None が入ってるときはあるし
str のつもりが None が入ってるときもある
int のつもりの変数に None が入ってても何もおかしなことではない
そもそも型宣言がないんだから
131:デフォルトの名無しさん
10/03/17 12:46:14
>>130
変数側の問題じゃなくて、int()の戻り値の問題。
int や str みたいな型は関数形式で呼び出してインスタンスを作るけど、
assert isinstance(sometype(), sometype)
という暗黙の了解があるの。
引数が悪くてその型の値を返せないときは例外を投げるべき。
132:デフォルトの名無しさん
10/03/17 12:48:40
sqlite3 とかでレコード取り出したときに str だと思ってたのに None が入ってるときがあるね
133:デフォルトの名無しさん
10/03/17 12:49:47
sがstrだとして
s.decode('utf-8')
みたいな使い方をしてるときに
sがNoneで例外出ると萎える
134:デフォルトの名無しさん
10/03/17 13:35:54
上では
int(s) -> parseできなければ例外
int(s, base) -> 同じ
int(s, default=...) -> parseできなければdefaultを返す
int(s, base, default=...) -> 同じ
こういう感じの話をしてたんだと思うが
default=を指定しなければ今と全く同じだし
parse不能なケースはデフォルト値で置き換えでいい場合は
try/exceptを含む4行程度のコードが式一つ圧縮できるわけだろ
default=Noneと「わざわざ」指定してNoneが返った場合の対応を「しない」のは
さすがに考えにくいんじゃないの
135:デフォルトの名無しさん
10/03/17 13:43:13
>>134
だから、int()にint以外のオブジェクトを返させるなって。
136:デフォルトの名無しさん
10/03/17 14:03:13
というか可能性としてはint.parseの方がよっぽど高いだろうに
コンストラクタでやろうとするほうが議論の中心になるのが納得できない
まぁ意固地なヤツのせいで議論にすらなってないわけだが
137:デフォルトの名無しさん
10/03/17 14:11:10
本家フォーラムで話さない時点で可能性の話をしても意味ないと思うの
138:デフォルトの名無しさん
10/03/17 14:34:45
別に正直どうでもいいが
つまり>>134がint()じゃなくてint.parse()でなければ特にケチをつける
理由は無いということ？
139:デフォルトの名無しさん
10/03/17 14:35:28
×int.parse()でなければ
○int.parse()であれば
140:デフォルトの名無しさん
10/03/17 14:49:34
>>138-139
int()と別にint.parse()を用意するのであれば、今度は例外を投げる必要がなくて、
default=0かdefault=Noneで良い。
というのが >>120 に既出
141:デフォルトの名無しさん
10/03/17 14:58:20
なるほど
142:デフォルトの名無しさん
10/03/17 21:11:41
誰か話まとめて
143:デフォルトの名無しさん
10/03/17 21:29:45
Ruby最高
144:デフォルトの名無しさん
10/03/17 22:22:10
int.parse() は int がオブジェクトじゃないからクラスメソッドが使えないって話
>>134 なら
ちゃんと
>default=Noneと「わざわざ」指定してNoneが返った場合の対応を「しない」のは
>さすがに考えにくいんじゃないの
と断ってあるので
>>135 みたいな突っ込みをする香具師はただのKYアホだと思う
145:デフォルトの名無しさん
10/03/17 22:23:30
>>134 最高
146:デフォルトの名無しさん
10/03/17 23:08:43
parse_intでも自作しろよ
147:デフォルトの名無しさん
10/03/17 23:13:10
仮にintにdefualtがある場合、defaultの型がint,longでないときに例外出せばいい
148:デフォルトの名無しさん
10/03/18 01:52:28
結局今の仕様通り、例外処理が一番スマートってことかな？
149:デフォルトの名無しさん
10/03/18 01:53:55
int()が関数でなく型(のコンストラクタ?)だってのは理解してるので、
必ずしも int を拡張しなくてもよいんだけど、
Battery includedを唱うPythonで、プロジェクト起こすたびに
同じ関数を作ってるのがちょっぴりイヤ。
どこか適当なモジュールに xint() とか parseInt() とか入れてくれないかな。
150:デフォルトの名無しさん
10/03/18 02:08:03
>>149
そんな頻繁にparseInt使いたくなるか？
intに直せないかもしれない未知の文字列をintにしたいときってどういう場合だ？
直せなかったときの対処は0入れるとか、None入れるとかで本当に適切なのか？
その場でエラー出した方がいいんじゃないの？
151:デフォルトの名無しさん
10/03/18 02:13:29
大抵の場合は
n = int(s) if isdigit(s) else None
で十分。符号とか前後スペースとか考えると面倒くさくなるが。
152:デフォルトの名無しさん
10/03/18 02:44:49
なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
周囲の環境を否定することでしか自我を保てない哀れな野郎だ
153:デフォルトの名無しさん
10/03/18 03:29:35
珍しくPythonスレが伸びてるからみんな暇つぶしで付き合ってるんじゃないの
154:デフォルトの名無しさん
10/03/18 03:58:42
>>152
愚痴しか言えないお前もなw
155:デフォルトの名無しさん
10/03/18 09:21:21
イベントにしか興味がなくて仕事をしない不思議な動物を飼っておく余裕はなくなったのだよ。
156:デフォルトの名無しさん
10/03/18 09:26:36
がんばれアイちゃん
157:デフォルトの名無しさん
10/03/18 09:31:32
292 デフォルトの名無しさん [sage] 2010/03/18(木) 07:15:50 ID: Be:
なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
周囲の環境を否定することでしか自我を保てない哀れな野郎だ
293 デフォルトの名無しさん [sage] 2010/03/18(木) 09:29:56 ID: Be:
＞C#は糞
＞ｽﾚﾘﾝｸ(tech板)l50
＞711 名前： デフォルトの名無しさん [sage] 投稿日： 2010/03/18(木) 02:50:41
＞なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
＞周囲の環境を否定することでしか自我を保てない哀れな野郎だ
＞C#終了のお知らせ
＞ｽﾚﾘﾝｸ(tech板)l50
＞292 名前： デフォルトの名無しさん [sage] 投稿日： 2010/03/18(木) 07:15:50
＞なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
＞周囲の環境を否定することでしか自我を保てない哀れな野郎だ
ｗｗｗ
158:デフォルトの名無しさん
10/03/18 10:12:26
>>149
予めあったらいいね。chomp とかもね
159:デフォルトの名無しさん
10/03/18 10:20:55
rstrip
160:デフォルトの名無しさん
10/03/18 11:00:20
>>159 いちいち rstrip("\r\n") と書くのがめんどい
161:デフォルトの名無しさん
10/03/18 11:17:55
じゃあ外出て彼女でも作れよ
162:デフォルトの名無しさん
10/03/18 11:20:17
>>160
てめぇPerlに喧嘩売ってんのか
163:デフォルトの名無しさん
10/03/18 11:23:11
>>160
改行は削除したいがtrailing spaceは保存したいケースってそんなに多いかなあ
164:デフォルトの名無しさん
10/03/18 11:33:02
ほんの数タイプ削減するためだけに、 parseInt や chomp を別に用意する必要は無い。
165:デフォルトの名無しさん
10/03/18 11:51:08
>>151
つまり、符号や前後スペースの問題等を考慮すれば、結局
def int_parsable(s):
try:
int(s)
return True
except:
return False
のような馬鹿馬鹿しいものを書くことになるわけでしょ
現実のプログラムで
ValueError: invalid literal for int() with base 10: ....
が最適なエラーメッセージだと考える人はいないだろうし
自分しか使わないオモチャをのぞけば、デフォルトの例外投げっぱなしが
最適解であることはむしろ稀なんじゃないの
166:デフォルトの名無しさん
10/03/18 11:59:17
わらた
167:デフォルトの名無しさん
10/03/18 12:02:23
>>165
そんなばかばかしい関数書かないよ。
ユーザーが入力した文字列を利用するなら、
try:
x = int(s)
except Exception:
# ユーザーにメッセージを表示
# x を使った処理
で十分。
>>151みたいな書き方をすることはない。
168:デフォルトの名無しさん
10/03/18 12:06:39
>>167
try～exceptを含む4つの文より、一つの式のほうが簡潔な上に、
抽象化された構造に取り込みやすいこともあるんじゃないの
>>151の右辺は式だからね
ああ書きたければ、isdigit()では不十分なので
int_parsable()が必要になる、ということ
169:デフォルトの名無しさん
10/03/18 12:08:28
これが日本のレベル
170:デフォルトの名無しさん
10/03/18 12:09:25
>>153
それもこれも、みんな俺の努力の賜でね
171:デフォルトの名無しさん
10/03/18 12:10:04
下手な回復されるよりは例外出される方がマシじゃん
172:デフォルトの名無しさん
10/03/18 12:11:27
そして
ValueError: invalid literal for int() with base 10: ....
を印字して終了するわけか
173:デフォルトの名無しさん
10/03/18 12:32:04
>>168
>>151みたいに書いたって、その後で
if n is None:
# ユーザーにまともなエラーメッセージを表示
ってやったら三行じゃん。
>>165でエンドユーザーに対してエラーメッセージを表示することについて
言っているけど、Noneなんて入れっぱなしにしたら
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
みたいなエラーがその後のどっか別の場所で出て、エンドユーザーにとって判りにくいどころか
プログラマにとってもいつint以外のオブジェクトが入ったのか探す必要が発生するわけだが。
174:デフォルトの名無しさん
10/03/18 12:36:33
>>173
int_parsable()では、デフォルト値でいい場合に
n = int(s) if int_parsable(s) else default
で済み、明らかに少ないし、
Value Error以外の、もっと有用なメッセージを出力したい場合も
if not int_parsable(s): raise ほげException(有用なメッセージ)
の1行で済むよ
175:デフォルトの名無しさん
10/03/18 12:38:20
つまり、防御的に書かない書き捨てコードの
...
n = int(s)
...
に対して、
...
if not int_parsable(s): ....
n = int(s)
...
と一行はさむだけで防御的になるわけだ
176:デフォルトの名無しさん
10/03/18 12:52:46
仕事しろよこの穀潰しが
177:デフォルトの名無しさん
10/03/18 12:54:36
>>174
デフォルト値で良い場合は >>51 で良いし、
例外メッセージを書き換えたい場合は
def int_parse(s, msg):
try:
return int(s)
except Exception:
raise HogeException(msg)
とした方が良いな。
このあたりはアプリケーション毎に違うんだから自分で書いたらいい。
178:デフォルトの名無しさん
10/03/18 14:31:51
春休みになるとここまで雰囲気が変わるのかよ
179:デフォルトの名無しさん
10/03/18 14:34:58
社内ニートも加わってさらにひどいことに．
180:デフォルトの名無しさん
10/03/18 15:26:30
つーか、まだやってたのか
181:デフォルトの名無しさん
10/03/18 15:40:43
質問です。
Pythonのコマンドラインを起動して、「3+4」と入力すると「7」が帰って来ます。
この「7」って__doc__とか__name__のどこかに格納されているのでしょうか？
また、「7」の型を判定することは可能でしょうか？
182:デフォルトの名無しさん
10/03/18 15:44:04
何が聞きたいのかさっぱりわからん
$ python
Python 2.6.4 (r264:75706, Jan 25 2010, 09:01:01)
[GCC 4.4.2 20091208 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3+4
7
>>> _
7
>>> type(_)
<type 'int'>
>>>
183:デフォルトの名無しさん
10/03/18 15:50:08
#型の判定
isinstance(7,int)
True
isinstance("7",int)
False
#数値型に変換できるかの判定
"7".isdigit()
True
"'7'".isdigit()
False
184:デフォルトの名無しさん
10/03/18 16:08:33
>>182-183
「_」と「typeやisinstance」がまさに知りたかった情報です。
ありがとうございます。
でも不思議なのですが、dir()しても「_」というオブジェクトは見つかりません。
「_」の情報はどこに定義されているのでしょうか？
185:デフォルトの名無しさん
10/03/18 16:15:47
__builtins__._
186:181
10/03/18 16:28:45
>>185
納得しました。
ありがとうございます。
187:デフォルトの名無しさん
10/03/18 16:45:25
この春厨は同じ春厨でも筋のいい春厨だから仲良くな。
188:デフォルトの名無しさん
10/03/18 18:05:51
皆さんいかがお過ごしでしょうか。
ストレス解消に煽りに来ている方、十分な睡眠を取って煽ってくださるようお願い申し上げます。
風邪を引く前の予防が肝心です。日々の鍛錬を怠らないようにして下さい。
暇つぶしに来ている方、時間を決めて一時間ごとに十五分から二十分くらいの休息を取られた方が良いと思います。
時間は限られています。あなたの人生はあなたの物ですが、一日中インターネットに没頭している、これはいかがな物でしょうか。
インターネットはあなた様の健康に悪影響を及ぼす可能性があります。
マルチしている方、人を忘れないでください、すべてはたくさんの人の多大な努力と膨大な時間を費やして出来た物でありますが故に、
そのような行為は非人道的行為にあたります。なお九十割はスクリプトで出来ているので、気軽に質問してください。マルチはいけません。
さて、私がこのような事をなぜ申し上げますかというと、この度Goのビルドに成功したが故に存じ上げる次第でございます。
よくよく冷静に考えると、このような開発段階にあり、現段階では実用に適していない「ぼくのかんがえたさいきょうのげんご」は
プログラミング言語の学習に適さないと判断させていただきました。今後ますますのご健康とご活躍をお祈り申し上げます。
189:デフォルトの名無しさん
10/03/18 18:27:07
長文は縦読みかどうかしか確認しないのが俺のジャスティス（キリ
190:デフォルトの名無しさん
10/03/18 19:15:58
>>188
特定しました
191:デフォルトの名無しさん
10/03/18 21:08:19
>>175
それ、1行挟むだけで済ませようと思ったらreturnかexitくらいしか入らないんじゃない？
192:デフォルトの名無しさん
10/03/18 21:09:15
>>191
raiseもいれられるお！
193:デフォルトの名無しさん
10/03/18 21:15:19
ってかマジレスすると、
その1行が想定している意味は、すぐ上の>>174を読めば分かる
194:デフォルトの名無しさん
10/03/18 21:16:55
なんてかpersable()がないのは、変換する必要がない場面で変換可能かを調べる必要が滅多にないこと、
変換する必要がある場面で例外にしてはいけない合理的理由が特に見当たらないこと、その2点に集約されてる気がする。
(Python
195:デフォルトの名無しさん
10/03/18 21:23:01
途中で書き込んでしまった。すまそ
(pythonでは例外使うことに抵抗がなく、むしろ積極的に使っている節がある。
それに、何もかもを1行で書きたいという欲求に、Guideは全然興味を示してない。
多分、三項演算子ができたのも、論理演算子を組み合わせた直感的でない方法取られるよりはマシとの判断)
str.indexとstr.findが両方あることを考えるに、
intが例外を返すのが直感的でない、例外を返さないことに意義がある場面が十分ありうるのなら、
既にparse_intは取り入れられてるはずだろう。
196:デフォルトの名無しさん
10/03/19 01:08:04
>>195
strにfindとindexの2種類合ってintには無い理由の大きな理由は、 str.find と str.index が
メソッドなのに対して str は組み込み型だからだと思うよ。
197:デフォルトの名無しさん
10/03/19 01:52:26
>>196
確かにそれも大きいとは思うが、それこそparse_intにすればいいって話になってくる。
一応、変換手段が複数ある例として、
str(u'abc')があるのにu'abc'.encode('ascii')が用意されているといったケースがある。
(これは、どっち使ってもUnicodeEncodeError例外が出うるけど)
198:デフォルトの名無しさん
10/03/19 02:34:10
ignoreが付いてるんだから
int()にもignoreがあればいいのにって話
199:デフォルトの名無しさん
10/03/19 02:52:29
いい加減そういうモジュール作るとか俺々Python作るとかすればいいじゃん
なんのためのOSSだ
200:デフォルトの名無しさん
10/03/19 03:15:23
>>197
最初から int に加えて parse_int みたいなのを加える事を言ってる。
"メソッド" はクラスの名前空間に属するけど、 int() に並べて parse_int() を追加しようとすると
組み込みの名前空間を汚しちゃう。
>>198
ignore付けたら何を返せばいいの？ 0 だと "0" を問題なくパースできたのと見分けがつかないよ。
201:デフォルトの名無しさん
10/03/19 03:38:07
>>198
だから、んなもんあってもバカがバカな使い方してバグ増やす以外に何のメリットもないと。
202:デフォルトの名無しさん
10/03/19 07:51:51
>>200
>ignore付けたら何を返せばいいの？ 0 だと "0" を問題なくパースできたのと見分けがつかないよ。
もちろんそれでいい
そのためのignoreなんだから
u'hoge'.encode('fuga', errors='ignore')
だって問題なくエンコードできたのと区別つかないでそ？
203:デフォルトの名無しさん
10/03/19 08:06:34
型変換とエンコードを一緒にされちゃいました
204:デフォルトの名無しさん
10/03/19 09:08:52
語るに堕ちたなw
エンコードっつても
unicodeとstrの型変換だぞ
205:デフォルトの名無しさん
10/03/19 10:25:08
ゆるしてやれ
206:デフォルトの名無しさん
10/03/19 11:00:26
Pythonではもともとstr型があったところにunicode型が導入されたという歴史的経緯がある
Python3では文字列型がunicode型に統一されている
以上のようなことから、unicode <-> strの型変換は特殊な位置づけにあると思う
207:デフォルトの名無しさん
10/03/19 11:14:34
Python3でもstrのコンストラクタで相変わらずerrors='ignore'と書けるわけだが…
それ、strのコンストラクタにerrors="ignore"と書けるのは良くて
intではダメ、という合理的な論拠や説明にはちっともなってなくね？
「特殊」ってつまり何？
なんかのマジックワードか何か？
208:デフォルトの名無しさん
10/03/19 11:16:48
>>200
str(b'\xff', errors='ignore')
''が返るね、問題なくパースできたのと見分けがつかないよね
なんつうか前から思っていたが、しばしばPython信者の擁護は見苦しくて妄信的だね
209:デフォルトの名無しさん
10/03/19 11:19:32
まあ ignore を「敢えて」指定するのは
> 問題なくパースできたのと見分けがつかないよね
を覚悟の上でやっているわけで。
違う型を返しているわけでもないし
210:デフォルトの名無しさん
10/03/19 11:21:06
>>209
よく読もう
例えば>>200の最後の文は滑稽でしかないということだよ
strのことは忘れたかのように、握り潰せるインタフェースは邪悪だと
彼らは主張していたわけだからね
211:デフォルトの名無しさん
10/03/19 11:51:48
まだこんなくだらない話を続けているのか。
Pythonの仕様に文句があるなら、作者の見てるとこで言えよ。
こんなとこで言っても変更される可能性は0だろう。
それでも駄目なら、自分で新しい言語を作ればいい。
212:デフォルトの名無しさん
10/03/19 11:53:07
2chやこのスレの存在意義を問うレスが来ました
そろそろ春だなあ厨も来る頃ですね
213:デフォルトの名無しさん
10/03/19 11:53:39
春厨は書き込みのすべてが滑稽
214:デフォルトの名無しさん
10/03/19 11:58:46
>>202
>>>200
>>ignore付けたら何を返せばいいの？ 0 だと "0" を問題なくパースできたのと見分けがつかないよ。
>
>もちろんそれでいい
>そのためのignoreなんだから
いや，この仕様はないわ、滑稽
型変換に失敗したときに0を返すべきかどうかは実装依存だし、
「じゃあdefaultをつけようぜ！ xxにはあるじゃん！」
などと付け足すとしたら恥の上塗り
ぜんぜんPythonicじゃないよ
215:デフォルトの名無しさん
10/03/19 11:59:59
頑張るねえ
216:デフォルトの名無しさん
10/03/19 12:02:40
>>210
>彼らは主張していたわけだからね
脳内には300人の「彼ら」が居るわけだね。
217:デフォルトの名無しさん
10/03/19 12:05:47
おまえらレベル高すぎ
218:デフォルトの名無しさん
10/03/19 12:07:03
>>216
2人以上いるときは複数形を使うのが正しいんだよ
君は日本語の勉強からやりなおしたほうがいいんじゃないかな
219:デフォルトの名無しさん
10/03/19 12:24:23
春厨はなかまになりたうそうにこっちをみている
なかまにしますか？
220:デフォルトの名無しさん
10/03/19 12:44:40
そういう実装は色々と問題があるから
エラー吐かせてるのに何で不毛な議論するの？
221:デフォルトの名無しさん
10/03/19 13:04:32
unicodeとstrの変換は、途中で例外出されたときに手動でハンドリングするのが難しい。
intは簡単だから、オプションを必要と言う主張が弱いだけ。
222:デフォルトの名無しさん
10/03/19 13:12:03
>>214
def int(str, , errors='strict', default=0):
で定義して erros='ignore'
223:デフォルトの名無しさん
10/03/19 13:13:49
途中で送ってしまった
>>214
def int(s, base, errors='strict', default=0):
で定義して erros='ignore' のときは default (もちろん変更可能) を返せば良い
224:デフォルトの名無しさん
10/03/19 13:15:04
,ひとつ多くね？
225:デフォルトの名無しさん
10/03/19 13:29:42
>>223
221
226:デフォルトの名無しさん
10/03/19 13:31:25
「じゃあdefaultをつけようぜ！ xxにはあるじゃん！」
などと付け足すとしたら恥の上塗り
227:デフォルトの名無しさん
10/03/19 14:38:15
そろそろ次の話題マダー? ちんちん
228:デフォルトの名無しさん
10/03/19 14:45:59
メールの MIME-multipart のデコードをしようと思っているのですが
Content-encoding と実際のデータのエンコードが違っているときがあります
適切に文字コードを判断してデコードするにはどのようにプロ倉民すればよいでしょうか
出力は UNICODE に統一出来ていれば良いです
229:デフォルトの名無しさん
10/03/19 15:06:29
1. もちついてタイピングする事
2. 右見て左見てもう一度右見て気をつけて渡る
230:デフォルトの名無しさん
10/03/19 15:16:09
ι''ゃぁ、次の話題。
a = [2,2,5,6,3,8,9] とかいうリストがあって、これを "," 区切りの文字列にしたいな、と思ったとき
a
",".join(a)
",".join(map(str, a))
の順番でタイプすることが多いんだけど、この順番だとキャレットが行ったり来たりしてちょっとストレス感じます。
lambda が入ったりして少し複雑な文とかでも、最終的に書かなければいけない順番と
頭で考える順番が全然イコールになってなくて、イライラっとするんだけどこういう事って結構ない？
231:デフォルトの名無しさん
10/03/19 15:48:18
Lispなら構文木は簡単に弄れるよ
232:デフォルトの名無しさん
10/03/19 16:40:03
py使いならXMLでやるんじゃね
知らんがな
233:デフォルトの名無しさん
10/03/19 16:49:34
UNICODE必要な処理はperlをパイプで呼び出して処理すればいいじゃん
234:デフォルトの名無しさん
10/03/19 16:50:37
URLﾘﾝｸ(groups.google.co.uk)
lispよりOCamlもいいなあ
235:デフォルトの名無しさん
10/03/19 16:55:54
python使いならYAMLしか選択がない
236:デフォルトの名無しさん
10/03/19 16:57:31
pythonの原型らしいbootというのがいまだに使われてるプロジェクトがあった
bootってpythonとどこまで互換あるんだろ
237:デフォルトの名無しさん
10/03/19 18:10:03
>>234
PythonもLispもOCamlも全部やればいいと思うよ！
238:デフォルトの名無しさん
10/03/19 20:55:28
>>230
Pythonでは、リストやジェネレータの内包表記があるからmapはあんまり使う必要がない。
",".join(str(n) for n in a)
って書き方だと、ちょっとは書きやすくなるんじゃないかなぁ。
239:デフォルトの名無しさん
10/03/19 20:59:16
>>208
変換できない文字は引数で指定した通りignoreした上で、変換可能な文字はすべて何ら問題なく変換している。
それは極めて正当な処理だ。
240:デフォルトの名無しさん
10/03/19 21:12:01
>>238
','.join(str(n) for n in a)
','.join(map(str, a))
元のほうが短くないか？
241:デフォルトの名無しさん
10/03/19 21:19:36
>>238
str(n) の n って for n で初めて意味が決まるので、
内包表記も頭から順番に書いていくには素直な順番じゃないなぁと思う。
内包表記に if が出てきたり多重ループになってたりすると
読んでも理解しづらいし、書きたいときも手が止まる。
242:デフォルトの名無しさん
10/03/19 21:29:18
perlでは処理できる日本語がpythonで処理できないのは
UTFに変換できない文字が入ってるから？
それ以外のケースってある？
243:デフォルトの名無しさん
10/03/19 21:30:35
>>242
処理できなかったのって具体的にどんな奴
244:デフォルトの名無しさん
10/03/19 21:33:25
エンコーディングにsjisを指定しているのなら、cp932にしたら
幸せになるかもしれない
euc-jpを指定しているのなら、euc_jisx0213にしたら幸せになるかもしれない
245:デフォルトの名無しさん
10/03/19 21:50:30
>>242
お前の脳が日本語を処理出来ないことは良くわかった
246:デフォルトの名無しさん
10/03/19 22:54:20
>>240
ごめ、長さのこと考えてなかった。
そのへん気になる人は、
','.join(str(n) for n in a)よりは','.join(map(str, a))の方が短く、
','.join(map(lambda n:str(n+1), a))よりは','.join(str(n+1) for n in a)の方が短いことを考えながら使い分けるとよい。
>>241
あまりに複雑な内包表記が読みづらいことは認める。
後置での読み書きは慣れの問題だとは思うが、Pythonは内包表記も三項演算子も後置的で、慣れないとPythonは使い辛いのかもしれない。
(cond ? true_value : false_valueをpythonでは true_value if cond else false_valueってかく)
意味、というか値が後で決まる件に関しては、関数だって定義したときには引数の値決まってないじゃん、って思うといいよ。
「とりあえず、str(n)する。で、そのnってのは...のことで」という読み方をすると割と読めるんじゃないかなぁ。
書くときは、自分の中で、シーケンスの中身を表す変数ってのがだいたい固定化してきたら書きやすくなる。
例えば俺はrange(10)の中身だとiで、文字列ならsで、整数ならnで、とりあえず何か要素ならelemって書くことが多い。
247:デフォルトの名無しさん
10/03/19 22:58:41
殺伐としていた本スレになにがあった
248:デフォルトの名無しさん
10/03/20 02:14:51
内包表記とかS式とかって、日本語の語順と逆だから違和感があるよね。
やっぱ、FORTHかな。
249:デフォルトの名無しさん
10/03/20 13:20:48
日本語と比べて違和感が、などと言っている英語駄目なエンジニアに未来はないけどね。
250:デフォルトの名無しさん
10/03/20 13:22:46
>>248
スタックマスターﾊｹｰﾝ
251:デフォルトの名無しさん
10/03/20 13:27:21
>>249
Shut your fuckin' mouth!!!!!
252:デフォルトの名無しさん
10/03/20 14:26:55
# 空白と改行を消す。
s = s.replace( "\n", "" ).replace( " ", "" );
こんな書き方しないとダメなの？
253:デフォルトの名無しさん
10/03/20 14:32:26
s.translate(None, " \n")
254:デフォルトの名無しさん
10/03/20 15:25:26
ボクチムは英語で罵倒できるほど英語ができるんだけど日本語と比べて違和感が
などと言っている奴はエンジニアである前に人間として駄目だけどね
255:デフォルトの名無しさん
10/03/20 15:32:27
>>254
Take a flying fuck
256:デフォルトの名無しさん
10/03/20 23:28:00
WiresharkのビルドにPythonが必須なんだが
Cygwin同梱のPythonではダメでWin32ネイティブのものが
インストールされてる必要がある
URLﾘﾝｸ(www.wireshark.org)
PerlはCygwin版で良いのにPythonは何故ダメなのか不思議
どうせWin32ネイティブのPythonが必要なら
Perlやbashその他もろもろをPythonで置き換えて
Cygwinインストール不要にして欲しい
subversionやNSISは仕方がないとして
Perl, bash, bison, flex, diff, patch, wget, unzip
なんかはPythonで置き換えられるよね？
257:デフォルトの名無しさん
10/03/21 07:35:03
そもそも関数が前置記法で欧米的。
日本語的とか言ってるような奴はそこから批判すべき。
258:デフォルトの名無しさん
10/03/21 07:43:31
>>257 LLスレで好きなだけやっとれ
259:デフォルトの名無しさん
10/03/21 09:45:11
いいじゃん、Pythonはオランダ語的ってことで。
len(s)はV1語法で、s.join(l)はV2語法だよ。
260:デフォルトの名無しさん
10/03/21 10:43:27
>>257
単にOO風の記述と関数的な記述が入り乱れてるから混乱するって話じゃねーの？
261:デフォルトの名無しさん
10/03/21 11:13:15
これがPython文法だと言われれば別に反発する気が起きない。
昔は強制インデント文法だけ取り上げられてマゾ言語と言われてたが
最近はあんまり言われなくなったなぁ。
今はモジュール・クラス・関数の命名の統一のなさがどうにも気になる。
Python4できっちり整備して欲しい。
262:デフォルトの名無しさん
10/03/21 11:20:57
母語がなんであれ、人間の思考は SOV の語順が一番自然というのを聞いたことがある。
絵を見せて、パントマイムでそれをつたえるという作業をさせると、SOVの順の人が一番多いのだそうだ。
263:デフォルトの名無しさん
10/03/21 11:23:25
naming style を統一しなかったのは、まずJavaやPosixみたいな既存の関数の
port版はそっちと名前を合わせたほうが使いやすいから統一しない、統一しないの
であれば、古いからっていう理由だけでpep8に従ってないモジュールのインタフェースを
無理に変える必要も無いよね－、という考えでそのままになってる。
パッケージ名だけは小文字で統一された。それ以外の分は、Threadingモジュールみたいに
段階的にエイリアスを定義しては古い方をdeprecated扱いにする・・・を繰り返して、
ゆっくり移行していくと思うよ。Python4から！みたいに線引きすると移行がしづらくなるから。
264:デフォルトの名無しさん
10/03/21 23:27:03
>>256
yaccやlexって標準添付ライブラリで置き換えられるんだっけ？
265:デフォルトの名無しさん
10/03/22 17:39:35
LL言語なんてperlがあれば十分なのに，なんで
RubyだのPythonなんてものができたんだ？
266:デフォルトの名無しさん
10/03/22 17:51:04
perlがキモいから
267:デフォルトの名無しさん
10/03/22 18:02:16
perlがゴミだから
268:デフォルトの名無しさん
10/03/22 18:56:42
いあPerlもPythonも必要
ゴミはRuby
269:デフォルトの名無しさん
10/03/22 18:59:49
どうぞどうぞ。
270:デフォルトの名無しさん
10/03/22 19:03:55
いやそれ以前にLispがあったのになんでPerlなんてできたんだ？
271:デフォルトの名無しさん
10/03/22 19:05:42
PerlとPythonとtclは要るな
make testで使われてる事が多いから
rubyは要らね
272:デフォルトの名無しさん
10/03/22 19:08:49
>>270
()//////
273:デフォルトの名無しさん
10/03/22 19:09:32
ちがった。
\\\\\\\\
274:デフォルトの名無しさん
10/03/22 20:12:29
>>271
たしかに
そこにrubyを含めると
rubyのテストをしないといけなくなる
275:デフォルトの名無しさん
10/03/22 20:17:15
>>274
は？
276:デフォルトの名無しさん
10/03/22 20:27:24
なにそれこわい
277:デフォルトの名無しさん
10/03/22 20:27:38
ひ！
278:デフォルトの名無しさん
10/03/22 20:36:43
rubyは好事家が趣味でコッソリ使う言語だよな
日本でこんなに広まったのがそもそもの間違い
279:デフォルトの名無しさん
10/03/22 21:31:14
RPGツクールとかいうブラック企業が制作したソフトウェアに組み込まれた言語だからな
280:デフォルトの名無しさん
10/03/22 22:04:15
RPGツクールは同コンセプトでもっとまともなものが出てもいい
言語別ゲーム用ライブラリは敷居が高すぎる
あ、敷居が高いからいいのか
281:デフォルトの名無しさん
10/03/22 22:09:16
RPGツクールは知らんがDANTE98とチャイムズクエストは神
282:デフォルトの名無しさん
10/03/22 23:59:57
Pythoneerだな
283:デフォルトの名無しさん
10/03/23 03:05:02
NetHackのGUIをpythonで作ってください
284:デフォルトの名無しさん
10/03/23 03:10:40
どうぞどうぞ
285:デフォルトの名無しさん
10/03/23 17:15:47
Python 2.6.5/3.1.2リリース
URLﾘﾝｸ(sourceforge.jp)
286:デフォルトの名無しさん
10/03/24 00:40:22
他のLL言語との比較は
ｽﾚﾘﾝｸ(tech板)
でやれ
287:デフォルトの名無しさん
10/03/24 00:46:19
どうぞどうぞ
288:デフォルトの名無しさん
10/03/25 12:26:27
python26_d.lib
ってどこか落ちてないのか
289:デフォルトの名無しさん
10/03/25 12:46:59
自分でデバグビルドすれば作れるし
自分でビルドしないのなら特に用のないファイルじゃないの？
290:デフォルトの名無しさん
10/03/25 13:39:36
>>289
pythonを部品として使ってるプロジェクトがビルドできない
291:デフォルトの名無しさん
10/03/25 13:49:24
>>290
ああ、それをデバグビルドしたくて、デバグ版はpython26_d.libにリンクするように
なってるわけな
実際にデバッガで動かそうと思ったら、それだけじゃなくて色々いると思うよ
最低限python26_d.dll、あとネイティブモジュール（pyd）も全部_d版が必要
そのプロジェクトは誰が作ったの
赤の他人？
292:デフォルトの名無しさん
10/03/25 14:14:25
sourceforgeってpythonなんだ
293:デフォルトの名無しさん
10/03/25 17:22:33
pythonのWebフレームワークでロードバランスなど負荷分散方法が組み込まれてるのってある？
294:デフォルトの名無しさん
10/03/25 21:22:22
>>293
Zopeが入ってるっぽいが
295:デフォルトの名無しさん
10/03/25 22:55:03
Zope(笑)
296:デフォルトの名無しさん
10/03/26 00:39:06
最近は何が流行りなんだdjangoか
GAEのおかげでpython使ってる人は増えてるみたいだけど
297:デフォルトの名無しさん
10/03/26 00:57:22
URLﾘﾝｸ(www.google.co.jp)
djangoダントツ
298:デフォルトの名無しさん
10/03/26 05:30:23
わかってて引用してるだろ？ｗ
299:デフォルトの名無しさん
10/03/26 12:33:37
djangoはロードバランスできないのか？
300:デフォルトの名無しさん
10/03/26 13:01:05
無茶いうな
301:デフォルトの名無しさん
10/03/26 19:54:37
>>293
Pylonsに入ってるっぽい
302:デフォルトの名無しさん
10/03/26 20:47:33
なんでWebフレームワークで負荷分散するんだよ？
フロントにnginx使って、バックにDjangoを複数立ち上げておけよ。
303:デフォルトの名無しさん
10/03/26 23:42:54
JTHONやCPYHONなどパイソン関連用語が多くて
学習する前に混乱しそうなんですけど、難しくないですか？
304:デフォルトの名無しさん
10/03/26 23:49:46
>>303
両方綴り間違ってるから釣りっぽいけど、
どの言語も同じようなもんだし、最初は気にする必要もない
305:デフォルトの名無しさん
10/03/27 15:11:37
Jythonで作ったスクリプトをコンパイルして
classファイルやjarファイル作りたいんだけどどうやるの？
306:デフォルトの名無しさん
10/03/27 15:24:51
ctypesとswigどっちがいいんだろう
OpenCVにデフォでついてるswigがなんか嫌なんだけど
307:デフォルトの名無しさん
10/03/27 18:30:41
>>306
原因不明のエラーが出ても気にならないならOpenCvSwing版でもいいが
ちゃんと使いたいならcvtypesとか使ったほうが安心できる
ROI使えないとかpython仕様じゃない実装されてる風だったり
かなりストレスたまる
308:307
10/03/27 18:31:27
下げそこないｽﾏｿ
309:デフォルトの名無しさん
10/03/28 00:11:15
cvtypes ってなんですか
310:デフォルトの名無しさん
10/03/28 01:20:23
URLﾘﾝｸ(code.google.com)
自分はこれを使ってた。
swig版やcvtypesと違ってちゃんとメモリを自動的に開放してくれるから便利だった。
311:デフォルトの名無しさん
10/03/28 01:42:27
ひょっとすると ctypes-opencv のことを略して cvtypes と言うのですか？
312:デフォルトの名無しさん
10/03/28 01:44:16
opencvでPyPIれ
313:デフォルトの名無しさん
10/03/28 01:46:09
Related Python wrappers for OpenCV
OpenCV has its own swig-based Python wrapper. However, it has conflicts
in memory management between C/C++ and Python, and hence is not suitable
for large projects. It is also particularly hard to maintain and develop.
Another project called CVtypes was pioneered by Michael Otto and is
currently maintained by Gary Bishop
(at URLﾘﾝｸ(wwwx.cs.unc.edu)).
The wrapper is based on ctypes. It supports a large set of OpenCV's
functions and a limited set of OpenCV's structures.
I used to provide some improvements to CVtypes here and there. While
Gary Bishop was a kind professor, I felt not so nice to keep asking him
to update his code. Therefore, I decided to branch from his CVtypes,
and the result is this project. ctypes-opencv supports a fairly complete
set of OpenCV's structures and functions. More importantly, I have put
a lot of efforts in making ctypes-opencv faster, better memory-managed,
and easier to use, by not only adopting but also improving the pythonic
interface introduced by OpenCV's developers. Nevertheless, credits should
also go to OpenCV developers, and CVtypes' authors and contributors.
I intend to eventually merge back to Gary Bishop's CVtypes when the project
is mature enough.
314:デフォルトの名無しさん
10/03/28 03:53:26
>>302
Ruby on RailsだとMongrelとかいうのが負荷分散してくれるみたいなんだけど
Pylonsにも似たような機能はあるのかな
315:デフォルトの名無しさん
10/03/28 04:02:08
OpenCV2.0のswigもメモリー漏れあるのだろうか
316:デフォルトの名無しさん
10/03/28 04:26:56
>>314
tornado使えばwsgi対応のフレームワークは全て出来るんじゃないかな
317:デフォルトの名無しさん
10/03/28 06:22:50
Visual StudioのExpress版でIPython出してくれたら本気出す
318:デフォルトの名無しさん
10/03/28 07:24:30
>>314
Mongrelでも一緒だ。
複数のMongrelを立ち上げて、フロントはApacheかnginxみたいなリバースプロクシを使って
負荷分散する。
319:デフォルトの名無しさん
10/03/28 13:26:50
ロードバランシングはフレームワークのレベルで行う事ではないってことか
320:デフォルトの名無しさん
10/03/28 13:34:04
振り分けクンを前に置くのが普通だと思っていたぜ・・・LBするくらいの環境なら。
321:デフォルトの名無しさん
10/03/28 20:44:16
しかしDjangoの日本語テキストって本当に少ないな
Pythonとセットで始めたいけど英語読めないから無理だわ・・・
322:デフォルトの名無しさん
10/03/28 21:14:15
DjangoはTurboGearsやPylonsより圧倒的に日本語情報多いと聞いたが
323:デフォルトの名無しさん
10/03/28 21:18:02
ドジャンゴは本まで出てるしな
324:デフォルトの名無しさん
10/03/28 21:30:42
Djangoはソースコードも追いやすいし書籍無しでいけるんじゃね
Railsは俺のレベルでは無理だった
325:デフォルトの名無しさん
10/03/28 22:03:14
ドジャンゴじゃなくてダンジョーだろ
326:デフォルトの名無しさん
10/03/29 02:03:56
日本のドジャンゴとゾープユーザは糞だよな
327:デフォルトの名無しさん
10/03/29 02:06:04
初めまして、糞です
328:デフォルトの名無しさん
10/03/29 02:10:24
ぼくはPHPからダンジョーでパイソンに興味を持ちまして、相変わらず糞コードを書いてますウンチです
329:デフォルトの名無しさん
10/03/29 07:48:46
URLﾘﾝｸ(djangoproject.jp)
330:デフォルトの名無しさん
10/03/29 12:32:51
OpenCVに限定しない一般の場合でも
swigよりctypesが推奨ってことでいいのだろうか
331:デフォルトの名無しさん
10/03/29 12:43:50
ctypesはパフォーマンスがあまりよろしくないみたいだから
既存のライブラリ利用→ctypes
新規で作成→swig
がいいかなと思ってる
あと使った事ないけどPyCXXが面白そう
332:デフォルトの名無しさん
10/03/29 15:58:22
SIP は？
333:デフォルトの名無しさん
10/03/29 20:31:40
Boost.Pythonってのもある
334:デフォルトの名無しさん
10/03/29 20:44:39
Pyrex/Cython
335:デフォルトの名無しさん
10/03/29 20:44:50
cython
336:デフォルトの名無しさん
10/03/29 21:55:41
Python/C APIだけで書く人はいないのか
337:デフォルトの名無しさん
10/03/29 22:21:45
>>336
bazaarその方向を目指してるようだ
338:デフォルトの名無しさん
10/03/30 18:14:47
Pythonどころかプログラミング自体初心者ですが、
Pythonの勉強はPython設計者本人が書いたという「Pythonチュートリアル第2版」でしようと思ってます。
大丈夫ですよね？
339:デフォルトの名無しさん
10/03/30 20:57:12
駄目です
340:デフォルトの名無しさん
10/03/30 21:03:42
無駄です
341:デフォルトの名無しさん
10/03/30 21:10:51
童貞です
342:デフォルトの名無しさん
10/03/30 21:15:14
ひどい
343:338
10/03/30 21:16:05
なぜですか？
344:デフォルトの名無しさん
10/03/30 21:24:07
プログラミング初心者用ではないからじゃないかなぁ
まあ、別に読んでも害はないけど
文句は言うな！
345:デフォルトの名無しさん
10/03/30 21:25:53
もう買っちゃったのなら三章から読んでいって
わけわかんないところは読み飛ばせばなんとかなるよ！
たぶん
346:デフォルトの名無しさん
10/03/30 21:26:19
>>343
みんぱい
はじぱいは？
347:デフォルトの名無しさん
10/03/30 21:28:06
はじぱいは悪くないけど信者がキモいよ。
348:デフォルトの名無しさん
10/03/30 21:28:52
>>338
みんぱいいいよみんぱい
349:デフォルトの名無しさん
10/03/30 21:30:34
みんぱいはいいけどアンチがキモイよ
350:デフォルトの名無しさん
10/03/30 21:36:49
みんなのぱいぱい
351:デフォルトの名無しさん
10/03/30 21:36:56
ゆえにプログラミング初心者向けのPython書籍はございません
352:デフォルトの名無しさん
10/03/30 22:20:47
川の向こうでRubyが手招きしている
353:デフォルトの名無しさん
10/03/30 22:22:48
三途の川？
354:デフォルトの名無しさん
10/03/30 22:28:13
荒川だな
355:デフォルトの名無しさん
10/03/30 22:32:23
みんなのPythonのひどさ。
URLﾘﾝｸ(tabesugi.net)
356:デフォルトの名無しさん
10/03/30 22:37:52
Rubyずきには申し訳ないが、
Rubyがもし日本で生まれていなければ悩むことなく、みなPythonを選択し、
もっと日本のPythonコミュニティが発展していたのかもしれないとおもうと、
なんか複雑な気分だなあ。
357:デフォルトの名無しさん
10/03/30 22:38:21
な，アンチキモいだろ？
358:デフォルトの名無しさん
10/03/30 22:40:23
>>357
にいやまはああいう芸風なんだよ(w
359:デフォルトの名無しさん
10/03/30 22:52:33
pythonの肩持つ気はないがrubyってそんな日本人に支持されてるのかね？
360:デフォルトの名無しさん
10/03/30 23:07:06
大型の書店にいってPythonとRubyの書籍の比率をみればあきらかだろ。
361:デフォルトの名無しさん
10/03/30 23:10:47
悩んだ末にRubyとRailsの本3冊かって全部読んだけど
結局なじめなくてPythonやってる
362:デフォルトの名無しさん
10/03/30 23:13:12
dive into なんかは、ただで読めるだろ
363:デフォルトの名無しさん
10/03/30 23:16:20
いままでは最初にバイブル本を読破してから
プログラミングに一気にとりかかるのが自分のやりかただったけど、
Pythonは本読む必要もなかった。
ドキュメントのグーぐるで十分。それくらい楽勝な言語。
364:デフォルトの名無しさん
10/03/30 23:21:30
Rubyで初めてプログラミング始める人は理解しやすいのだろうが
javaとかC#とかやってるとRubyは凄く気持ち悪い
365:デフォルトの名無しさん
10/03/30 23:53:36
Tutorialだけで十分。
日本語訳は正確じゃなかったり、くどかったりすることもあるので、オリジナルを読むのが吉。
366:デフォルトの名無しさん
10/03/30 23:58:35
俺もC++とJavaから来たが、PythonよりRubyのほうが書いてて気持ち良いなぁ。
でも、他人が書いたソース読むんなら、断然Pythonだな。
367:デフォルトの名無しさん
10/03/31 00:08:03
[The ruby sniffer]
whenever they have ruby coding, they stay focus to what ruby.
that doing is like sniffing ruby code, actually, they might sniff ruby code.
why... I guess because that is goddamn flaw of ruby.
how flaw, I could answer... exactly they are like sniffer.
368:デフォルトの名無しさん
10/03/31 01:09:14
PILで作った画像をsaveするときに
ファイルではなくメモリ上のバッファに
出力したいのですが、具体的には
im = Image.new('RGBA', (sizex, sizey))
im.putpixel((x, y), color)
...
#im.save('hoge.gif') ←ここのかわりに
s = StringIO.StringIO()
im.save(s)
あとで s.read() で別の部分に使うような感じです
s のところが f = open('hoge.gif', 'wb') みたいに
file オブジェクトなら正常に動作するのですが
StringIO だと (file オブジェクト互換のつもり) 書き込めません
やはり file オブジェクトにしか出力出来ないのでしょうか？
369:デフォルトの名無しさん
10/03/31 01:22:16
im自体をメモリ上に持つのはだめなの？
一応tostringっていうメソッドはあるみたいだけど
370:338
10/03/31 01:31:57
Tutorialって日本語訳として出版されたものでないと、
書籍の形にはなってないんですか？
371:デフォルトの名無しさん
10/03/31 01:41:29
You can use a file object instead of a filename.
In this case, *** you must always specify the format. ***
The file object must implement the seek, tell, and write methods, and be opened in binary mode.
372:デフォルトの名無しさん
10/03/31 01:42:36
>>368
im.save(s, 'gif')
かな。format指定しないとダメと思う。
fileオブジェクトの場合は .name の拡張子から
フォーマット判断してくれる(たしか
373:デフォルトの名無しさん
10/03/31 01:48:12
>>369
ありがとうございます
tostring() だと pixel 部分の sequence のみ？とか良くわからないデータになってしまいます
所謂ファイルに出力されるそのままのイメージでバイナリでメモリ上に持ちたかったので・・・
>>371
ありがとうございます
解決しました
s = StringIO.StringIO()
im.save(s, 'gif')
でうまくいきました
そのあと試しに
s.seek(0)
open('hoge.gif', 'wb').write(s.read())
とやったら同じファイルが作成されました
374:デフォルトの名無しさん
10/03/31 01:50:31
>>372
ありがとうございます
リロードずれたので行き違いになってしまいました
結果は >>373 の通りです
375:デフォルトの名無しさん
10/03/31 13:31:34
初心者的な質問で申し訳ありませんが
a = open("hage.txt", "r")
for b in a.readlines():
fugafuga
a.close()
と書くのと
for b in open("hage.txt", "r").readlines():
fugafuga
と書くのと(close書かない&ファイルオブジェクトの参照を変数に持たない)
どっちが良いですか？
376:デフォルトの名無しさん
10/03/31 14:06:20
readlinesすると全部読み込んでメモリ上に乗ってしまうから
バカでかいファイルを読み込むと死ねます。
ということで、
with open("hoge.txt") as f:
for line in f:
fugafuga
がいいと思います。
こう書くとwithのブロックが終わった直後に f が自動でcloseされます。
377:デフォルトの名無しさん
10/03/31 19:44:36
for line in open("hoge.txt"):
fugafuga
378:デフォルトの名無しさん
10/03/31 20:21:13
ファイルの最後3行だけ読みたいときに perl だと
open(F, "tail -3 /hoge/fuga/hage.txt | ");
while(<F>){
print $_;
}
みたいな書きかたが出来たと思いますが
python だとどう書けばよいのでしょうか？
379:デフォルトの名無しさん
10/03/31 20:46:56
URLﾘﾝｸ(lmgtfy.com)
380:デフォルトの名無しさん
10/03/31 20:48:45
pipeがやりたいならsubprocess.Popenだけど、もっとPythonicな方法がありそう
import subprocess
path = "tail -3 lazy.py"
f = subprocess.Popen(path, stdout=subprocess.PIPE).stdout
for line in f:
print line,
f.close()
381:デフォルトの名無しさん
10/03/31 20:50:46
空白置換すんの忘れてた……
import subprocess
path = "tail -3 /hoge/fuga/hage.txt"
f = subprocess.Popen(path, stdout=subprocess.PIPE).stdout
for line in f:
print line,
f.close()
382:デフォルトの名無しさん
10/03/31 21:31:07
(´ﾟ c_,ﾟ｀)ﾌﾟｯ
383:デフォルトの名無しさん
10/03/31 23:34:05
pipe使わないならこんな感じか？
limit = 3
lis = []
for line in open('/hoge/fuga/hage.txt ', 'r'):
if len(lis) >= limit:
lis[:-limit+1] = []
lis.append(line)
print ''.join(lis)
384:デフォルトの名無しさん
10/04/01 01:26:32
tailは前から読み込んで捨てていくんじゃなくて、後ろから読みながら指定行をゲットしたい。
385:デフォルトの名無しさん
10/04/01 01:45:36
>>383
前から全部読むにしても、せめてdeque使ったほうがいいな
file-like objectがseekableなら、
URLﾘﾝｸ(stackoverflow.com)
この辺で
386:デフォルトの名無しさん
10/04/01 02:25:17
>>380
できました
ありがとうございました
subprocess.Popen で気になるのは
stdout だけ close() してるので
stdin とか stderr とかは close() 書かなくても大丈夫なのかどうかってことです
387:デフォルトの名無しさん
10/04/01 02:28:50
>>378
PythonスレにPerlのコードを貼るな
汚いから誰も見たくないだろう
388:デフォルトの名無しさん
10/04/01 05:01:16
正直に言うとlinux環境だとちょっとしたプログラムなら
ついperlで書いてしまうんだよ、ごめんね
389:デフォルトの名無しさん
10/04/01 05:24:19
>>388
ゆる
390:デフォルトの名無しさん
10/04/01 08:47:21
>>388
一人でこっそり書くなら許す
391:デフォルトの名無しさん
10/04/01 12:46:13
>>388
ぜったいにゆるさない
392:デフォルトの名無しさん
10/04/01 12:55:37
>>388
Perlのコードを人に見せるなんて、
おな(ryを人に見せるのと同じだ！！
393:デフォルトの名無しさん
10/04/01 13:37:37
perlの様なもので殴られた後があり
394:デフォルトの名無しさん
10/04/01 14:55:27
sageに入ってるpythonはデフォで色々入ってるのはいいけど
日本語通らないね
395:デフォルトの名無しさん
10/04/01 15:53:18
2.4 以前は糞
396:デフォルトの名無しさん
10/04/01 17:03:54
Tutorialって日本語訳として出版されたものでないと、
書籍の形にはなってないんですか？
397:デフォルトの名無しさん
10/04/01 17:06:26
Ｐｙｔｈｏｎスレで聞くのもなんだが、ＬＬ内で１つ覚えるならＰｙｔｈｏｎ？
Ｐｅｒｌに劣ってることってある？
398:デフォルトの名無しさん
10/04/01 17:07:13
Pythonのバイブル本って何なんですか？
Ｃでいうカーニハン＆リッチー的な
399:デフォルトの名無しさん
10/04/01 17:10:34
そんなものはねえ
400:デフォルトの名無しさん
10/04/01 18:29:20
>>397
Perlキモイ、Ruby氏ねな俺でもPythonがベストとは言わない
Pythonよりも目標に向いてる言語があるならそっち使った方がよい
401:デフォルトの名無しさん
10/04/01 18:30:55
>>397
起動が遅い。
Webプログラミング以外の用途も考えているのなら、
Pythonを進めるが。
402:デフォルトの名無しさん
10/04/01 18:37:27
今までプログラム書いたことないなら
Perl より Python の方を薦めるよ
いきなり Perl から始めると変な癖つくからね
403:デフォルトの名無しさん
10/04/01 18:50:42
まぁスクリプト言語学びたいならLinux使えよ
スペックあるならWinでもVMWare使えばいいし
404:デフォルトの名無しさん
10/04/01 18:52:50
Linuxを学びたいならLinuxを学べばいいが、
スクリプト言語を学ぶのにわざわざOS環境まで用意する必要は無い。
405:デフォルトの名無しさん
10/04/01 18:56:47
>>398
信者と言われそうだがはじぱいなんかそれに近いんじゃないか？
406:デフォルトの名無しさん
10/04/01 18:59:15
東京キャビネットにperlとrubyのバインディングあるのにpythonがないのは何で？
ＬＬ言語間とWebプログラミングに派閥みたいなもがあるのかな？
407:デフォルトの名無しさん
10/04/01 19:05:01
>>460
pytc
408:デフォルトの名無しさん
10/04/01 19:10:01
>>397
1つ覚えるならPerlじゃないか？
どこのWebサーバ借りても大抵は最新のが使えるのは有りがたい。
Pythonはいまだに2.3なんてとこもある。
ただし、PythonにはGAEという無料で使える最強のサーバが存在するので、
自分で1からWebサービス作りたいとかならPythonが有利ではある。
ぶっちゃけ、1つ覚えたら他のなんてリファレンス片手に1日で使えるようになるから、
何を覚えるかなんて気にしなくていい。
409:デフォルトの名無しさん
10/04/01 19:13:06
Perl Rubyはライブラリの充実度や汎用性からいってにありえないな。
日本はWebプログラミング中心に語れることがおおいから
Pythonに人気無いんだと思う。
410:デフォルトの名無しさん
10/04/01 19:15:08
日本語が不自由だということはよくわかった
411:デフォルトの名無しさん
10/04/01 19:15:47
Pythonに人気がないのはRubyの作者が日本人でみんなそっちに流れていくからじゃないのか
412:デフォルトの名無しさん
10/04/01 19:20:03
いや日本ではWeb以外のプログラマにスクリプト言語がまだまだ普及して無いからだと思うよ。
ハード系エンジニアで面倒なときにPythonつかうことがあるんですが、
こっちの世界の人はC/C++書いてるくせにスクリプト言語といっても通じない人が多いんです。
413:デフォルトの名無しさん
10/04/01 19:34:24
そういう奴らはbashすら使えないクズだろ
414:デフォルトの名無しさん
10/04/01 19:37:34
まあクズだね。
自分シェルスクリプトなんてやらないけど。
VHDLとかハード記述言語は本業なので使えるけど。
415:デフォルトの名無しさん
10/04/01 19:40:44
Pythonが教育で使われてるのはコードが綺麗で変な癖がないというのもあるだろうけど、
ほかのスクリプト言語が応用範囲が狭すぎるってのがでかいな。
研究用途ではPerlが一部あるけど、Rubyなんてほとんどないのでは?
PythonはPerlやRubyだけでなくてJavaなどとも競合している言語です。
Webだけで言語の優劣論はできないと思うよ。
416:デフォルトの名無しさん
10/04/01 19:43:51
だからPythonもPerlもJavaも使えるようになれよ
こんな所で駄レスしてる間に覚えられるっつーの
417:デフォルトの名無しさん
10/04/01 19:53:07
アプリケーションのモジュール書くという実際の要求があって
採用されてるのがPythonだった俺に選択の自由はなかった
418:デフォルトの名無しさん
10/04/01 19:55:39
Pythonは研究用途でも使われてますよ
419:デフォルトの名無しさん
10/04/01 19:56:54
いつも書くたびに思うがサーバーサイドのスクリプト言語の中ではPythonが1番いいよね。
420:デフォルトの名無しさん
10/04/01 19:57:24
Python も Ruby もこの世に存在していなくて
HTML すら無かった時代だったから
Pascal とか C くらいしか魅力なかったな
FORTRAN や COBOL は論外
421:デフォルトの名無しさん
10/04/01 20:00:06
論外と思う言語でも使わざるを得ないときもある。
大体最近の言語は文法を把握してコードがかけるようになるより、
ライブラリ把握してつかいたおうほうが時間がかかる。
422:デフォルトの名無しさん
10/04/01 20:00:17
Lispでいいから
423:デフォルトの名無しさん
10/04/01 20:04:51
>>416
そんなのわかった上で書いてるんだろう。
そもそもスクリプト言語なんてがんばって覚えるほどのものでもないだろう。
どうせ使うときにすぐ覚えられるんだからな。
どんな言語をつかってもだめなやつはだめ。
424:デフォルトの名無しさん
10/04/01 21:43:21
dbist_wininstでつくったらしい.exeってサイレントインストールできないのかな？
install directoryも編集できないしちょっと困る
425:デフォルトの名無しさん
10/04/01 21:57:29
setuptools入れて
python -m easy_install 424のexe
が一番楽だと思う。オプションである程度ディレクトリとかいじれる
426:デフォルトの名無しさん
10/04/01 22:18:23
easy_installに渡すのはすごくいい案！と喜んでやってみたら
share/ にデータつくるやつとかpost_installで.bat作るやつとか(ipython)は
無視されちゃいました。
でも柔軟なアイディアをありがとう
427:デフォルトの名無しさん
10/04/01 22:30:11
別にPythonのスレなんだからPythonいいよねぇ
みたいな話がでてきてもいいと思うんだが、
よくないと思ってるのに使ってる人が多いのかここは…w
初学者を追い払おうと変なやつが常駐しているみたいにみえる。
428:デフォルトの名無しさん
10/04/01 22:41:40
yam install -y (python-)[hoge]の方が楽だよね
429:デフォルトの名無しさん
10/04/01 22:51:05
>>426
setuptoolsはinstall_script/pre_install_scriptオプションに対応してないね
メタデータをexeに埋め込んでるけど探そうともしてないみたい
430:デフォルトの名無しさん
10/04/01 23:27:20
pass
431:デフォルトの名無しさん
10/04/01 23:29:02
URLﾘﾝｸ(github.com)
これネタなのかな
発想は面白いと思うんだけどｗ
432:デフォルトの名無しさん
10/04/02 01:46:13
Pythonの本は何が決定版なの？
433:デフォルトの名無しさん
10/04/02 01:54:51
今年発売されるExpert Python Programming
434:デフォルトの名無しさん
10/04/02 03:42:22
今から勉強するならPython 3がいいですよね？
でも人気のある本はだいたい2が主流で、3は2との違いを最後のほうに少し解説しているだけのようです。
どうすればいいでしょうか？
435:デフォルトの名無しさん
10/04/02 03:44:38
本とか関係なしに2がいいよ
436:デフォルトの名無しさん
10/04/02 05:33:55
python3は最新版じゃなくて永遠の実験場
437:デフォルトの名無しさん
10/04/02 07:06:04
Google App Engineとxreaが2だからずっと2でしか書いてない
438:デフォルトの名無しさん
10/04/02 07:17:18
みんなのpythonとはじめてのpythonどっちがいいですか？
439:デフォルトの名無しさん
10/04/02 13:00:21
とりあえずみんなのPython買えば？
440:デフォルトの名無しさん
10/04/02 13:05:57
>>438
君はみんなのPythonが似合ってると思うよ
URLﾘﾝｸ(twitter.com)
441:デフォルトの名無しさん
10/04/02 13:08:00
はじめての Python は
「初ぱい」と「恥ぱい」の二種類あるから要注意
後者は糞
442:デフォルトの名無しさん
10/04/02 13:14:17
>>440
真実と嘘の区別が付かないひとは 2ch に向かない
443:デフォルトの名無しさん
10/04/02 14:31:15
linuxのyum使うとwinでいちいちexe落とすの面倒になるな
もうwinのサポート切っちまうか
444:デフォルトの名無しさん
10/04/02 14:39:26
どうぞどうぞ
445:デフォルトの名無しさん
10/04/02 17:11:33
Macportsの壊れっぷりはなんとかならないのか
446:デフォルトの名無しさん
10/04/02 21:39:43
*BSD涙目6ぷぎゃー9
447:デフォルトの名無しさん
10/04/03 01:59:24
>>440
みっともねーｗ
448:デフォルトの名無しさん
10/04/03 03:08:04
Python環境作るとき真っ先にeasy_installを入れるんだけど、
標準に入れない理由ってなんだろ。
449:デフォルトの名無しさん
10/04/03 03:34:53
python自体の機能じゃないからかな
知らんけど
450:デフォルトの名無しさん
10/04/03 03:57:23
>>426
きちんと調べたけどwininst-*.exeにくっつけたリソースとかは探してた
でもpre_install_script/install_scriptは呼んでない
DATA/*以下を無視してるし、eggに全部固めるというポリシーなんだと思う
>>448
setuptools/distutilsはカオスさ半端ないし、上に書いてみたいに仕様が違ったりするし
誰もやりたがらないんじゃないの
451:デフォルトの名無しさん
10/04/03 10:53:05
Tarek Ziade ががんばってる。
Python 2.7 では easy_install が標準に入るはず。
しかもアンインストールもできるようになるはず。
452:デフォルトの名無しさん
10/04/03 10:58:59
わあいわあい
453:デフォルトの名無しさん
10/04/03 13:30:06
>Python 2.7 では easy_install が標準に入るはず。
これはどうでもいいけど
>しかもアンインストールもできるようになるはず。
こっちはありがたい
454:デフォルトの名無しさん
10/04/03 16:41:52
2.7なんてあるのか
2系は2.6で終わりかと思ってた
455:デフォルトの名無しさん
10/04/03 16:44:49
URLﾘﾝｸ(www.python.org)
456:デフォルトの名無しさん
10/04/04 04:50:39
>>451
easy_installを標準にするんならpypiを使い易いようにして欲しい。
457:デフォルトの名無しさん
10/04/05 14:16:48
>>451 >>453
distribute
easy_install -> pip
URLﾘﾝｸ(packages.python.org)
458:デフォルトの名無しさん
10/04/06 19:33:05
datetime.utcnow() でつくったdatetimeを、JSTに変換して出力したいんですが
どうしたらいいでしょうか。
>>> from datetime import datetime
>>> dt = datetime.utcnow()
>>> dt.strftime('%Y-%m-%d %H:%M:%S %Z')
'2010-04-05 00:09:44 ' # JST に変換して出力したい
マニュアルよんでもわけわかめです。
459:デフォルトの名無しさん
10/04/06 19:41:51
>>> from datetime import datetime
>>> dt = datetime.utcnow()
>>> tz = datetime.now() - datetime.utcnow()
>>> tz
datetime.timedelta(0, 32400)
>>> dt + tz
datetime.datetime(2010, 4, 6, 19, 40, 18, 922000)
>>> (dt + tz).strftime('%Y-%m-%d %H:%M:%S %Z')
'2010-04-06 19:40:18 '
460:デフォルトの名無しさん
10/04/06 19:47:22
なんかインチキっぽいな
461:デフォルトの名無しさん
10/04/06 19:55:19
大丈夫
462:デフォルトの名無しさん
10/04/06 22:32:50
JSTって分かってるんだったら
datetime.timedelta(0, 60*60*9)
でいいのでは？
463:デフォルトの名無しさん
10/04/06 23:31:37
そりゃそうだ
464:デフォルトの名無しさん
10/04/06 23:32:46
レンサバだと datetime.now() が何返すか判らんからなwww
465:デフォルトの名無しさん
10/04/07 00:16:10
サーバーサイドでユーザーのlocaleはpytzとかで自前解析だねえ
466:デフォルトの名無しさん
10/04/07 06:34:07
>>458
Pythonは標準ではタイムゾーン関係のクラスが用意されていないので、
class JST(datetime.tzinfo):
def utcoffset(self,dt):
return datetime.timedelta(hours=9)
def dst(self,dt):
return datetime.timedelta(0)
def tzname(self,dt):
return "JST"
みたいに自分で定義して、datetime.astimezone(JST())でJSTにする。
467:デフォルトの名無しさん
10/04/07 08:44:34
(´・ω・｀)
468:デフォルトの名無しさん
10/04/07 10:27:50
だれかが一覧を書いてくれればOKってこと?
サマータイムとかがうざくて面倒すぎるのかな
469:デフォルトの名無しさん
10/04/07 15:20:28
PyPyってGoogleのプロジェクトだったの？知らなかった。
URLﾘﾝｸ(google-opensource.blogspot.com)
470:デフォルトの名無しさん
10/04/07 15:38:30
それ読むとGoogleが金出してるみたいね
471:デフォルトの名無しさん
10/04/08 12:21:50
>>458
ドキュメントに載ってたこれをコピペして
class FixedOffset(tzinfo):
"""Fixed offset in minutes east from UTC."""
def __init__(self, offset, name):
self.__offset = timedelta(minutes = offset)
self.__name = name
def utcoffset(self, dt):
return self.__offset
def tzname(self, dt):
return self.__name
def dst(self, dt):
return ZERO
JST = FixedOffset(9*60, "JST")
でいいのかな。
472:デフォルトの名無しさん
10/04/08 18:07:54
>>468
URLﾘﾝｸ(www.python.jp)
＞世界各国における時刻の修正に関する法則は合理的というよりも政治的なものであり、全てのアプリケーションに適した標準というものが存在しないのです。
日本でも夏時間を導入するなんて議論がしょっちゅう行われているしねぇ。
今JSTを定義しても、数年後には変わっている可能性がなくもない。
473:デフォルトの名無しさん
10/04/08 18:27:37
理解できない。
JSTそのものを変更するんじゃなくて、
サマータイム版の標準時(JST-SummerTime)を導入すればいいだけじゃん。
てか「規格」ってそういうもんだろ？
IPがv4からv6になるかもしれないから、
ネットワーク関連のクラス入れないよとかありえないだろ？
474:デフォルトの名無しさん
10/04/08 20:02:32
>>473
っつーか日本が中共に飲み込まれたら
JST自体なくなってしまうかも試練ぞ
475:デフォルトの名無しさん
10/04/08 20:27:26
>>474こういうのいらないから誰か引き取って
476:デフォルトの名無しさん
10/04/08 21:04:16
いらないです(´；ω；`)
477:デフォルトの名無しさん
10/04/08 21:07:23
■ＡＡ対応チェック
┏━━━━━━━━━━━━━┓
┃ ┌────────┐ ┃
┃ │ .右のAAのｽﾞﾚない環境が標準モナ.｜ ┃
┃ └─y──────‐┘ ┃
┃ ∧＿∧ | |＼|／ | ｜ ｜ ┃
┃ （ ´∀｀） | ∧ ∧ |/⌒ヽ、| ∧＿∧ | ∧∧ | ┃
┃ （ つ |(,,ﾟДﾟ)||,,ﾟ Θﾟ）|（； ´Д｀）|(=ﾟωﾟ)| ┃
┗━━━━━━━━━━━━━┛
| | ｺｿｯ| |
| |∧_∧ ｼﾞｰ ∧_/.| | ＿＿
|＿|´◛ω◛`) .(´◛ω|＿| .[lШШl]
| | ｏ【◎】 ( o| | (´◛ω◛｀) ｼﾞｰ
|￣|―ｕ' ｀ｕ. |￣|｜| | | | |
"""""""" """"""""""""""""
┏━┯━━━━━━━━━━━━┓
┏━┻━┥ _,,.. ┃
┠──┤ ⊂⊃ ／,' 3~~＼ ⊂.⊃ ┃
┗━┳━┥..............,,,,傘傘傘::::::::傘傘傘............. おてもと ┃
┗━┷━━━━━━━━━━━━┛
┏━┯━━━━━━━━━━━━┓
┏━┻━┥ (⌒-⌒) お食事処 仔熊庵 ┃
┠──┤ ⊂⊃ (･(ｪ)･ ) ⊂⊃ ┃
┗━┳━┥..............,,,,傘傘傘::::::::傘傘傘............. おてもと ┃
┗━┷━━━━━━━━━━━━┛