[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 08/30 10:57 / Filesize : 148 KB / Number-of Response : 717
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Pythonのお勉強 Part37



1 名前:デフォルトの名無しさん mailto:sage [2010/03/13(土) 16:59:28 ]
Pythonオフィシャルサイト
www.python.org/
日本Pythonユーザ会
www.python.jp/Zope/
まとめWiki
python.rdy.jp/
関連スレ
find.2ch.net/?BBS=ALL&TYPE=TITLE&STR=python
前スレ
pc12.2ch.net/test/read.cgi/tech/1264924208/

116 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 00:55:44 ]
default の初期値は「未指定」でいいじゃない。
PyArg_ParseTupleAndKeywords()の書き方次第でNoneではない「未指定」のデフォルトにできるじゃんね。

int('abc') → ValurError
int('abc', 16) → 2748
int('abc', default=None) → None


117 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:13:30 ]
>>116
「未指定」なんてオブジェクトはない
あと、>>114で言っているように int() が None を返しちゃダメ。
intかintと上位互換のlongを返さないと。

118 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:22:55 ]
>>117
そういうオブジェクトはないけど、
def to_int(val, **kwargs):
 if 'default' in kwargs:
  pass
みたいな処理はできるってことを言いたいんじゃないかなぁ。

intがint以外のインスタンス返す仕様になってほしいとはまったくもって思わんけど。

119 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:34:12 ]
ビルドインを増やすのが嫌なら
int.parse(string)ってスタティックメソッドを作ればいいんじゃないかな

120 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:47:14 ]
>>117
それだと、今度は (val [, base [, default]]) という順序引数が使えなくなるね。
intが例外を投げる関数としてあるんだから、int以外の関数を使うなら
defaultは普通にNoneがデフォルト値の引数で良いんだよ。
問題は、大して利点無くビルトインを増やすこと。

>>119
うん、どうしてもdefaultが欲しいなら、それが一番Pythonicだね。
残る問題は、今のところ組み込み型にはstaticmethodが無いという事だけだ。
int.parseのためだけに組み込み型のstaticmethodを用意するのはやっぱり
無いだろうけど、他にも組み込み型staticmethodの要求が増えてきたら
ついでに int.parse が入るかも。

121 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 06:21:49 ]
def int(s, exception=True, default=0):

みたいに定義しといて
exception=False
で使ったときだけdefaultを返せば良いと思う

122 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 09:33:17 ]
型の変換はバリデータとかでさっくりやるんじゃねえの?
typeにstaticmethod追加するとかバカか?

123 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:18:34 ]
>>122
えっ

124 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:24:44 ]
>>122
元の要求は明らかに
unicode(s, 'utf-8', errors='ignore')
あたりからの類推だろうし、別にそんなに変な話じゃないと思うが



125 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:32:41 ]
別ディレクトリにある.pyファイルをimportしたい時って、sys.pathを直接いじるのが一般的なの?

126 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 10:38:56 ]
メインプログラムのサブディレクトリに配置すれば良いじゃん

127 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 11:03:58 ]
__import__() を使おう

128 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:36:00 ]
>>124
たしかにunicodeはencodingやerrrosを指定できるけど戻り値は必ずunicode型だろ
int(hoge, default=None)みたいにint以外返せるのはおかしい

129 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:36:50 ]
おいおい、まだやってたのか

130 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:41:03 ]
unicode のつもりが None が入ってるときはあるし
str のつもりが None が入ってるときもある
int のつもりの変数に None が入ってても何もおかしなことではない
そもそも型宣言がないんだから

131 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:46:14 ]
>>130
変数側の問題じゃなくて、int()の戻り値の問題。

int や str みたいな型は関数形式で呼び出してインスタンスを作るけど、
assert isinstance(sometype(), sometype)
という暗黙の了解があるの。

引数が悪くてその型の値を返せないときは例外を投げるべき。

132 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:48:40 ]
sqlite3 とかでレコード取り出したときに str だと思ってたのに None が入ってるときがあるね

133 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 12:49:47 ]
sがstrだとして
s.decode('utf-8')
みたいな使い方をしてるときに
sがNoneで例外出ると萎える


134 名前:デフォルトの名無しさん mailto:sage [2010/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 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 13:43:13 ]
>>134
だから、int()にint以外のオブジェクトを返させるなって。

136 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:03:13 ]
というか可能性としてはint.parseの方がよっぽど高いだろうに
コンストラクタでやろうとするほうが議論の中心になるのが納得できない
まぁ意固地なヤツのせいで議論にすらなってないわけだが

137 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:11:10 ]
本家フォーラムで話さない時点で可能性の話をしても意味ないと思うの

138 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:34:45 ]
別に正直どうでもいいが
つまり>>134がint()じゃなくてint.parse()でなければ特にケチをつける
理由は無いということ?

139 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:35:28 ]
×int.parse()でなければ
○int.parse()であれば

140 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:49:34 ]
>>138-139
int()と別にint.parse()を用意するのであれば、今度は例外を投げる必要がなくて、
default=0かdefault=Noneで良い。
というのが >>120 に既出

141 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 14:58:20 ]
なるほど

142 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 21:11:41 ]
誰か話まとめて

143 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 21:29:45 ]
Ruby最高

144 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 22:22:10 ]
int.parse() は int がオブジェクトじゃないからクラスメソッドが使えないって話

>>134 なら
ちゃんと

>default=Noneと「わざわざ」指定してNoneが返った場合の対応を「しない」のは
>さすがに考えにくいんじゃないの

と断ってあるので

>>135 みたいな突っ込みをする香具師はただのKYアホだと思う



145 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 22:23:30 ]
>>134 最高

146 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 23:08:43 ]
parse_intでも自作しろよ

147 名前:デフォルトの名無しさん mailto:sage [2010/03/17(水) 23:13:10 ]
仮にintにdefualtがある場合、defaultの型がint,longでないときに例外出せばいい

148 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 01:52:28 ]
結局今の仕様通り、例外処理が一番スマートってことかな?

149 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 01:53:55 ]
int()が関数でなく型(のコンストラクタ?)だってのは理解してるので、
必ずしも int を拡張しなくてもよいんだけど、
Battery includedを唱うPythonで、プロジェクト起こすたびに
同じ関数を作ってるのがちょっぴりイヤ。
どこか適当なモジュールに xint() とか parseInt() とか入れてくれないかな。


150 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:08:03 ]
>>149
そんな頻繁にparseInt使いたくなるか?
intに直せないかもしれない未知の文字列をintにしたいときってどういう場合だ?
直せなかったときの対処は0入れるとか、None入れるとかで本当に適切なのか?
その場でエラー出した方がいいんじゃないの?

151 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:13:29 ]
大抵の場合は
n = int(s) if isdigit(s) else None
で十分。符号とか前後スペースとか考えると面倒くさくなるが。

152 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 02:44:49 ]
なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
周囲の環境を否定することでしか自我を保てない哀れな野郎だ

153 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 03:29:35 ]
珍しくPythonスレが伸びてるからみんな暇つぶしで付き合ってるんじゃないの

154 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 03:58:42 ]
>>152
愚痴しか言えないお前もなw



155 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 09:21:21 ]
イベントにしか興味がなくて仕事をしない不思議な動物を飼っておく余裕はなくなったのだよ。

156 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 09:26:36 ]
がんばれアイちゃん

157 名前:デフォルトの名無しさん mailto:sage [2010/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#は糞
    >pc12.2ch.net/test/read.cgi/tech/1246520657/l50
    >711 名前: デフォルトの名無しさん [sage] 投稿日: 2010/03/18(木) 02:50:41
    >なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
    >周囲の環境を否定することでしか自我を保てない哀れな野郎だ

    >C#終了のお知らせ
    >pc12.2ch.net/test/read.cgi/tech/1200796178/l50
    >292 名前: デフォルトの名無しさん [sage] 投稿日: 2010/03/18(木) 07:15:50
    >なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな
    >周囲の環境を否定することでしか自我を保てない哀れな野郎だ


    www

158 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 10:12:26 ]
>>149
予めあったらいいね。chomp とかもね

159 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 10:20:55 ]
rstrip

160 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:00:20 ]
>>159 いちいち rstrip("\r\n") と書くのがめんどい

161 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:17:55 ]
じゃあ外出て彼女でも作れよ

162 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:20:17 ]
>>160
てめぇPerlに喧嘩売ってんのか

163 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:23:11 ]
>>160
改行は削除したいがtrailing spaceは保存したいケースってそんなに多いかなあ

164 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:33:02 ]
ほんの数タイプ削減するためだけに、 parseInt や chomp を別に用意する必要は無い。



165 名前:デフォルトの名無しさん mailto:sage [2010/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 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:59:17 ]
わらた

167 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:02:23 ]
>>165
そんなばかばかしい関数書かないよ。
ユーザーが入力した文字列を利用するなら、
try:
    x = int(s)
except Exception:
    # ユーザーにメッセージを表示
# x を使った処理

で十分。
>>151みたいな書き方をすることはない。

168 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:06:39 ]
>>167
try〜exceptを含む4つの文より、一つの式のほうが簡潔な上に、
抽象化された構造に取り込みやすいこともあるんじゃないの
>>151の右辺は式だからね

ああ書きたければ、isdigit()では不十分なので
int_parsable()が必要になる、ということ

169 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:08:28 ]
これが日本のレベル

170 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:09:25 ]
>>153
それもこれも、みんな俺の努力の賜でね

171 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:10:04 ]
下手な回復されるよりは例外出される方がマシじゃん

172 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:11:27 ]
そして
ValueError: invalid literal for int() with base 10: ....
を印字して終了するわけか

173 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:32:04 ]
>>168
>>151みたいに書いたって、その後で
if n is None:
    # ユーザーにまともなエラーメッセージを表示
ってやったら三行じゃん。

>>165でエンドユーザーに対してエラーメッセージを表示することについて
言っているけど、Noneなんて入れっぱなしにしたら

TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

みたいなエラーがその後のどっか別の場所で出て、エンドユーザーにとって判りにくいどころか
プログラマにとってもいつint以外のオブジェクトが入ったのか探す必要が発生するわけだが。

174 名前:デフォルトの名無しさん mailto:sage [2010/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 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:38:20 ]
つまり、防御的に書かない書き捨てコードの
...
n = int(s)
...

に対して、
...
if not int_parsable(s): ....
n = int(s)
...

と一行はさむだけで防御的になるわけだ


176 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:52:46 ]
仕事しろよこの穀潰しが

177 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:54:36 ]
>>174
デフォルト値で良い場合は >>51 で良いし、
例外メッセージを書き換えたい場合は

def int_parse(s, msg):
    try:
        return int(s)
    except Exception:
        raise HogeException(msg)

とした方が良いな。
このあたりはアプリケーション毎に違うんだから自分で書いたらいい。

178 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 14:31:51 ]
春休みになるとここまで雰囲気が変わるのかよ

179 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 14:34:58 ]
社内ニートも加わってさらにひどいことに.

180 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:26:30 ]
つーか、まだやってたのか

181 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:40:43 ]
質問です。

Pythonのコマンドラインを起動して、「3+4」と入力すると「7」が帰って来ます。
この「7」って__doc__とか__name__のどこかに格納されているのでしょうか?

また、「7」の型を判定することは可能でしょうか?

182 名前:デフォルトの名無しさん mailto:sage [2010/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 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 15:50:08 ]
#型の判定
isinstance(7,int)
True
isinstance("7",int)
False
#数値型に変換できるかの判定
"7".isdigit()
True
"'7'".isdigit()
False

184 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:08:33 ]
>>182-183
「_」と「typeやisinstance」がまさに知りたかった情報です。

ありがとうございます。

でも不思議なのですが、dir()しても「_」というオブジェクトは見つかりません。
「_」の情報はどこに定義されているのでしょうか?



185 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:15:47 ]
__builtins__._

186 名前:181 mailto:sage [2010/03/18(木) 16:28:45 ]
>>185
納得しました。
ありがとうございます。

187 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 16:45:25 ]
この春厨は同じ春厨でも筋のいい春厨だから仲良くな。

188 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:05:51 ]
皆さんいかがお過ごしでしょうか。
ストレス解消に煽りに来ている方、十分な睡眠を取って煽ってくださるようお願い申し上げます。
風邪を引く前の予防が肝心です。日々の鍛錬を怠らないようにして下さい。
暇つぶしに来ている方、時間を決めて一時間ごとに十五分から二十分くらいの休息を取られた方が良いと思います。
時間は限られています。あなたの人生はあなたの物ですが、一日中インターネットに没頭している、これはいかがな物でしょうか。
インターネットはあなた様の健康に悪影響を及ぼす可能性があります。
マルチしている方、人を忘れないでください、すべてはたくさんの人の多大な努力と膨大な時間を費やして出来た物でありますが故に、
そのような行為は非人道的行為にあたります。なお九十割はスクリプトで出来ているので、気軽に質問してください。マルチはいけません。
さて、私がこのような事をなぜ申し上げますかというと、この度Goのビルドに成功したが故に存じ上げる次第でございます。
よくよく冷静に考えると、このような開発段階にあり、現段階では実用に適していない「ぼくのかんがえたさいきょうのげんご」は
プログラミング言語の学習に適さないと判断させていただきました。今後ますますのご健康とご活躍をお祈り申し上げます。

189 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:27:07 ]
長文は縦読みかどうかしか確認しないのが俺のジャスティス(キリ

190 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 19:15:58 ]
>>188
特定しました

191 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:08:19 ]
>>175
それ、1行挟むだけで済ませようと思ったらreturnかexitくらいしか入らないんじゃない?

192 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:09:15 ]
>>191
raiseもいれられるお!

193 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:15:19 ]
ってかマジレスすると、
その1行が想定している意味は、すぐ上の>>174を読めば分かる

194 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:16:55 ]
なんてかpersable()がないのは、変換する必要がない場面で変換可能かを調べる必要が滅多にないこと、
変換する必要がある場面で例外にしてはいけない合理的理由が特に見当たらないこと、その2点に集約されてる気がする。
(Python



195 名前:デフォルトの名無しさん mailto:sage [2010/03/18(木) 21:23:01 ]
途中で書き込んでしまった。すまそ

(pythonでは例外使うことに抵抗がなく、むしろ積極的に使っている節がある。
それに、何もかもを1行で書きたいという欲求に、Guideは全然興味を示してない。
多分、三項演算子ができたのも、論理演算子を組み合わせた直感的でない方法取られるよりはマシとの判断)

str.indexとstr.findが両方あることを考えるに、
intが例外を返すのが直感的でない、例外を返さないことに意義がある場面が十分ありうるのなら、
既にparse_intは取り入れられてるはずだろう。

196 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 01:08:04 ]
>>195
strにfindとindexの2種類合ってintには無い理由の大きな理由は、 str.find と str.index が
メソッドなのに対して str は組み込み型だからだと思うよ。

197 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 01:52:26 ]
>>196
確かにそれも大きいとは思うが、それこそparse_intにすればいいって話になってくる。
一応、変換手段が複数ある例として、
str(u'abc')があるのにu'abc'.encode('ascii')が用意されているといったケースがある。
(これは、どっち使ってもUnicodeEncodeError例外が出うるけど)

198 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 02:34:10 ]
ignoreが付いてるんだから
int()にもignoreがあればいいのにって話

199 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 02:52:29 ]
いい加減そういうモジュール作るとか俺々Python作るとかすればいいじゃん
なんのためのOSSだ

200 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 03:15:23 ]
>>197
最初から int に加えて parse_int みたいなのを加える事を言ってる。
"メソッド" はクラスの名前空間に属するけど、 int() に並べて parse_int() を追加しようとすると
組み込みの名前空間を汚しちゃう。

>>198
ignore付けたら何を返せばいいの? 0 だと "0" を問題なくパースできたのと見分けがつかないよ。

201 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 03:38:07 ]
>>198
だから、んなもんあってもバカがバカな使い方してバグ増やす以外に何のメリットもないと。

202 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 07:51:51 ]
>>200
>ignore付けたら何を返せばいいの? 0 だと "0" を問題なくパースできたのと見分けがつかないよ。

もちろんそれでいい
そのためのignoreなんだから

u'hoge'.encode('fuga', errors='ignore')
だって問題なくエンコードできたのと区別つかないでそ?

203 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 08:06:34 ]
型変換とエンコードを一緒にされちゃいました

204 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 09:08:52 ]
語るに堕ちたなw
エンコードっつても
unicodeとstrの型変換だぞ



205 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 10:25:08 ]
ゆるしてやれ

206 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:00:26 ]
Pythonではもともとstr型があったところにunicode型が導入されたという歴史的経緯がある
Python3では文字列型がunicode型に統一されている
以上のようなことから、unicode <-> strの型変換は特殊な位置づけにあると思う

207 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:14:34 ]
Python3でもstrのコンストラクタで相変わらずerrors='ignore'と書けるわけだが…

それ、strのコンストラクタにerrors="ignore"と書けるのは良くて
intではダメ、という合理的な論拠や説明にはちっともなってなくね?
「特殊」ってつまり何?
なんかのマジックワードか何か?

208 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:16:48 ]
>>200
str(b'\xff', errors='ignore')
''が返るね、問題なくパースできたのと見分けがつかないよね

なんつうか前から思っていたが、しばしばPython信者の擁護は見苦しくて妄信的だね

209 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:19:32 ]
まあ ignore を「敢えて」指定するのは
> 問題なくパースできたのと見分けがつかないよね
を覚悟の上でやっているわけで。

違う型を返しているわけでもないし

210 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:21:06 ]
>>209
よく読もう
例えば>>200の最後の文は滑稽でしかないということだよ

strのことは忘れたかのように、握り潰せるインタフェースは邪悪だと
彼らは主張していたわけだからね

211 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:51:48 ]
まだこんなくだらない話を続けているのか。
Pythonの仕様に文句があるなら、作者の見てるとこで言えよ。
こんなとこで言っても変更される可能性は0だろう。

それでも駄目なら、自分で新しい言語を作ればいい。

212 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:53:07 ]
2chやこのスレの存在意義を問うレスが来ました
そろそろ春だなあ厨も来る頃ですね

213 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:53:39 ]
春厨は書き込みのすべてが滑稽

214 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:58:46 ]
>>202
>>>200
>>ignore付けたら何を返せばいいの? 0 だと "0" を問題なくパースできたのと見分けがつかないよ。
>
>もちろんそれでいい
>そのためのignoreなんだから

いや,この仕様はないわ、滑稽
型変換に失敗したときに0を返すべきかどうかは実装依存だし、
「じゃあdefaultをつけようぜ! xxにはあるじゃん!」
などと付け足すとしたら恥の上塗り

ぜんぜんPythonicじゃないよ



215 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 11:59:59 ]
頑張るねえ

216 名前:デフォルトの名無しさん mailto:sage [2010/03/19(金) 12:02:40 ]
>>210
>彼らは主張していたわけだからね

脳内には300人の「彼ら」が居るわけだね。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<148KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef