Pythonについて（アンチ専用）

Pythonが嫌いな人のためのスレッドです。

■関連スレ
Rubyについて（アンチ専用） Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/

Pythonは糞だよ

http://elliottback.com/wp/wp-content/uploads/2008/01/mergesort-performance.png

call/cc とマクロがないんだっけ？

自己書き換えも出来ないよ

PythonにはRubyのような熱狂がないから反動もないのでアンチスレは盛り上がらない

重複してないか

Pythonもアンチスレできたのかwww

ここは重複スレです

元スレはこちら
http://pc11.2ch.net/test/read.cgi/tech/1200210768/

================================
　　　　　　　　　糸冬　　了
================================

安置するも何も、そもそもよく知らない。

Blenderに採用されて世話になっている手前、Ruby使いだけどアンチできない

安置じゃないけれど len(x) よりむしろ x.len と記述したかった

あーそれは思った。len(hoge)ってvbsかよwって。
for i in range(1, len(hoge) - 1) :とかも萎えたな。

自由度ありすぎなlispは正規表現libraryすら標準のものがないらしい
pythonは不自由なのがよいのかも

でも不自由を極めると日本語プログラム言語「なでしこ」になっちゃうしな

不自由と感じるかある種のエレガンスと感じるかによって好き嫌いがわかれるのだろう

rubyに比べてなんとなくかっこよく見えるからむかつく

>>13
シーケンスの要素をループ内で使いたいなら

for i in hoge:

と書けばいい。

シーケンスの要素とカウンタを同時に得たいなら、

for c, i in enumerate(hoge):

とすればいい。
enumerateを知らないやつは厨房。

>>17
ruby よりかっこいいんで Python 使ってる

enumerate と iteritem ってどう違うの？

help(dict().iteritems)を実行すればおｋ

iteritems は辞書（ハッシュ、連想配列）の話、enumerate は一般のイテレータについて番号つけるって言うもの

>>> hoge = {'hage': 'fuga', 'hige': 'moga'}
>>> [(k, v) for k, v in hoge.iteritems()]
[('hage', 'fuga'), ('hige', 'moga')]
>>> [(k, v) for k, v in enumerate(hoge)]
[(0, 'hage'), (1, 'hige')]
>>>

なにこのアンチスレ(w
Pythonの人たちは親切だなあ(wwww

安置スレだったか
すまんこorz

>>> [(c, k, v) for c, (k, v) in enumerate(hoge.iteritems())]
[(0, 'hage', 'fuga'), (1, 'hige', 'moga')]

(´-`).oO(辞書の要素に番号…)

>18
要素でなくて、インデックスが欲しい時はどうすんのさ。

(´-`).oO(順番という概念のない辞書の要素にインデックス…)

>>27
for idx, __ in enumerate(L):
something(idx)

よくみろ
要素に番号振ってるんじゃなくて
キーに番号振ってるんだよ

>>13のhogeは辞書なの？

20あたりで辞書型のメソッドが出てきて、それ以来アンチスレに似つかわしくないこの流れ。

いわゆる「ツンデレ」やってやつだろ。

・ライブラリの命名規則がばらばら
・なにをするにも import sys, os
・既存の組込みクラスにメソッドが追加できない
・遅い
・self self self
・return return return
・print文、exec文ってなによ
・正規表現リテラルが無いよ
・lambdaが式しか受け付けないよ

>>32
(´-`).oO(アンチのレベルが低すぐるのが問題なんだよなぁ。。。)

イ　ン　デ　ン　ト (笑)

まず荒らしとアンチの違いから教える必要があるようだ...orz...

IronPythonのipc.pyでコンパイルされたexeが激遅で萎えた

>>38
Quad搭載PC買っちゃいなよ

print文はpython的にキモいけどなくなったらなくなったで
すげー不便になりそう。schemeみたいに仕様だけは美しいけど
使えない言語になりそう。

なくなるんだろう？

Python3 で関数になる
>>> print("hoge", 4, 5.67)
hoge 4 5.67

蛇（というか爬虫類全般）が苦手なので、名前を聞いただけで尻込みしてしまう。

なので、オライリーの本が買えない

逆に考えるんだ
おっぱいぱーそん→おっぱいそん
と考えるんだ

>>38
>IronPythonのipc.pyでコンパイルされたexeが激遅で萎えた
>>44
>オライリーの本が買えない

アンチって貧乏なのかな...?

>>46みたいな理解してない奴は来なくていいよ

(´-`).oO(相当気に障ったらしい。。。)

和製の初心者本が誰を対象にして書いたのかわからんクソ本ばかり

少なくともお前は相手にされてないから安心汁

(´-`).oO(お金がなくて立ち読みしたので内容がよく理解できていないんだろうか...)

>>47
アンチスレは単純な隔離スレだからな

>>44
オライリーのやつはヘビじゃなくて
ヘビに食べられる動物が載ってる。

アンチは頭が弱くて貧乏ってことで FA ?

貧乏でもPythonならドキュメントが揃ってるだろ

頭が弱いとオンラインドキュメントも読めないんだろうなぁ

日本語で書かれた出版物には大したものがないのでオンラインドキュメントを読みましょう
2.5 の日本語訳はまだありませんがきちんと読めば 2.4 でも充分に事足ります

2.4に載ってなくて重要な標準モジュールは
hashlibぐらいかな。
>>1のwikiに書いてあると思う。

(´-`).oO(なんのアンチなんだか。。。)

なにこのスレ・・・

× アンチ専用
× 低賃金基地外ITドカタ隔離専用

1のwikiを2時間探しましたが見つかりませんでした。

ざこには見えない

>>42
>>>> print("hoge", 4, 5.67)
>hoge 4 5.67
この仕様はウンコだよなあ
なんで勝手に空白が入ったり改行がついたりするんだよ

空白いれたくなければ、
print("%s%s%s" % (hoge, 4,5.67)
とすりゃいいんじゃないの。
改行いれたくなければ標準出力様にお願いしなさい:-)

print("%s%s%s" % (hoge, 4,5.67))
)が足りなかった

(´-`).oO(無知を仕様のせいにしてウンコとけなすのか...)

print 関数は互換性重視だろ。sep, end で調節できる。
print("hoge", 4, 5.67, sep="", end="")

自分のアプリにパイソン組み込んでみた。
久しぶりに脳汁がとまらない。

病人

隔離スレへようこそ。

2008-02-25 15:34:56　という文字列から datetime のインスタンスを作りたいとき

>>> time.strptime('2008-02-25 15:34:56', '%Y-%m-%d %H:%M:%S')
(2008, 2, 25, 15, 34, 56, 0, 56, -1)

から得られると思って
下のように実行してみたら

>>> datetime.datetime(time.strptime('2008-02-25 15:34:56', '%Y-%m-%d %H:%M:%S'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: function takes at least 3 arguments (1 given)

となってしまいました

>>> datetime.datetime(2008,2,25,15,34,56)
datetime.datetime(2008, 2, 25, 15, 34, 56)

だと問題ないのに何がいけないんでしょうか？

>>> datetime.datetime(*(time.strptime('2008-02-25 15:34:56', '%Y-%m-%d %H:%M:%S')[0:6]))
datetime.datetime(2008, 2, 25, 15, 34, 56)
>>> datetime.datetime.strptime('2008-02-25 15:34:56', '%Y-%m-%d %H:%M:%S')
datetime.datetime(2008, 2, 25, 15, 34, 56)

ありがとうございました

なにこのためになるアンチスレ(wwww

>>65
>print("%s%s%s" % (hoge, 4,5.67)
こんなコードを何の疑問にも思わないお前のオツムがあっぱれ

言っとくけど俺天才だからな

知ってるよ

>>78
お前だれだ？
トリップつけとく

>>77
Lisper ?

%の優先順位が無駄に強すぎてイラつく

print "%d" % 3 + 5
これはエラー

print "%d" % (3 + 5)
こうしないとダメ

print "%d"% 3 + " is the answer."
とかするときのためなのかもしれないが、こんな見にくいのこそ
print ("%d"% 3) + " is the answer."
とか
print "%d is the answer." % 3
ってやるから必要ないし。

%は演算子なのさ。
"%d" % 3 + 5の%は，文字列を左辺に，数値を右辺に取って，結果として文字列を返す。
その後文字列に数値を足そうとしているのでエラーになる。
それだけのこと。超シンプル。

演算子の優先順位は型によって変わらないから
数値型とか考えると % が + よりも強いのは自然だと思うが

文字列の場合は % の右辺は常に括弧で囲むようにするといいよ

なにこの協力的なアンチスレ(wwwwwwwwwwwww

ああ、昔
print '%s%s%s' % A, B, C
みたいなのでハマったの思い出したよ。
タプルは括弧いらないんじゃなかったのか？って。

ここは頭の弱い人はPythonを使えないことを証明するためのスレですね(w

変な挙動だから、よく知らないと戸惑うというだけの話でしょ。

挙動が変なのは82の頭。

Python脳ではないことが変の定義なら、確かに

演算子の優先順位云々ってのは算数レベルの知識だってことにいいかげん気付けよ。

タプルを自動展開するフォーマッティングはGuido とかも問題を感じてて
たとえば次みたいなときに何かおかしい

>>> "%s"%1
'1'
>>> "%s"%(1,)
'1'
>>> "%s"%((1,),)
'(1,)'

ということが指摘されてて、実際3.0ではこの仕組みは無くなる。

>>87
タプルが括弧いらないのはその通りだけど、
演算子の順位としては最弱(and or より更に弱い)なので、
その場合後ろの方が独立したexprになってしまう。
まあ、確かにカンマと+の順位とか普段考えないので嵌るといえば嵌る

>>92
Python脳の人がPythonに一切疑問を抱かないのは知ってるから、
そんなに一所懸命「後戻りできなくなったボクの脳を見て！」ってアピールしなくていいです。

と、さんすうにも四苦八苦なゆとりが申しております。

算数が平仮名なら、それより先に四苦八苦を平仮名にしないと
演出としてダメダメだと思うよ。

は？

>>96
大丈夫かお前

と、こくごに四苦八苦なゆとりが申しております。

3.0っていつごろ出る？

だれかわたしに挑戦しませんか？w

>>100
ttp://www.python.org/dev/peps/pep-3000/

>>101
アホを相手にする人はいません。

誰もお前の相手なんかしない、という内容で相手してる奴の頭って・・・

>>104
言うことを聞かないからといって何も注意しないのは罪だから。

勝手に事情聴取した防衛省とかね。

まあ、事故のときはまず身内に相談するのが当たり前ではあるけど。

>>int PyRun_SimpleStringFlags( const char *command, PyCompilerFlags *flags)
>>__main__モジュールの中でflags に従ってcommand に含まれる
>>Python ソースコードを実行します。
>>__main__がまだ存在しない場合は作成されます。
>>正常終了の場合は0を返し、また例外が発生した場合は-1を返します。
>>エラーがあっても、例外情報を得る方法はありません。
氏ね
普通に例外情報取得できるようにしろ

リファレンスはまったく詳細を書いていない。
ほとんど役に立たない。クズ同然。

>>100
西暦3000年

商業ベースに乗らないマイナースクリプト言語の問題はリファレンスがクズということだな

そうだな、言語リファレンスが存在しないRubyはクズ言語と言っていいよな。

パイソニスタの私がいうのもなんですが、
Pythonは屑言語の1つだと思います。
N88 BASICより使えない駄目言語。

>>110
それはない

パイソンにはLINE文もPAINT文もDATA文もないので
ミンメイが描けません！！
こんな屑言語を作った人は死ねばいいと思います！

>>112
import turtle

http://coreblog.org/ats/turtle-python-standard-module

Pythonにgotoがない時点で終わってると思います。
また安易にErrorキャッチに頼りやすい。
何が
try
except
だ。楽すぎて死ねるわ。
しかも最初からpdbなんていうデバッガもどきがついてるし

goto for Python
ttp://entrian.com/goto/

PLAY文が無い限りBASICには勝てない

PyAudio

The following only summarizes information from the PyAudio Web page.

PyAudio provides Python bindings for the PortAudio audio I/O library. The current version of PyAudio is V0.1.0, which is alpha quality.

Multi-platform
Package is compilable for MS-Windows, Apple Mac OS X, Linux and cygwin.
Real-time sound acquisition
Unknown
Support for 16KHz sampling rate and >8-bit sound
Unknown.
Sound file processing
Unknown.
Efficiency
Unknown.
Pitch existence and frequency
Unknown.
Formants and their bandwidths
Unknown.
FFT with pre-emphasis and Hamming window
Unknown.
Power
Unknown.

PyMedia.py

The documentation is very sketchy.

Multi-platform
Package is compilable for MS-Windows, Linux and cygwin.
Real-time sound acquisition
Unknown
Support for 16KHz sampling rate and >8-bit sound
Probably depends upon sound card.
Sound file processing
Yes.
Efficiency
Unknown.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

MCI.py (from Arik Baratz) together with ctypes.py

Multi-platform
ctypes.py is supported by all 32-bit MS Windows (95/98/NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSD/UNIX-like OSes), WinCE.
MCI.py was designed to communicate with MS-Windows winmm.dll.
Real-time sound acquisition
Unknown.
Support for 16KHz sampling rate and >8-bit sound
Unknown.
Sound file processing
Seems to be able to record to a file.
Efficiency
Commands are sent as strings.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

ossaudiodev

Multi-platform
Not enough. Implemented in Linux and FreeBSD. Available for a wide range of open-source and commercial Unices. But apparently not for MS-Windows.
Real-time sound acquisition
Blocking reads, by default. Probably can set to non-blocking.
Support for 16KHz sampling rate and >8-bit sound
Seems to depend upon the sound card.
Sound file processing
Use another package for this.
Efficiency
Direct I/O access.
Pitch existence and frequency
Use another package for this.
Formants and their bandwidths
Use another package for this.
FFT with pre-emphasis and Hamming window
Use another package for this.
Power
Use another package for this.

Snack

Multi-platform
The same scripts are usable on Windows 95/98/NT/2K/XP, Linux, Macintosh, Sun Solaris, HP-UX, FreeBSD, NetBSD, and SGI IRIX.
Real-time sound acquisition
Yes.
Support for 16KHz sampling rate and >8-bit sound
Yes.
Sound file processing
Yes.
Efficiency
Inefficient - data is converted into string by the Tcl part of the package and then converted back into data by the Python part.
Pitch existence and frequency
Yes. Each 10mSec, using the ESPS method (the ADMF method is available, too).
Formants and their bandwidths
http://www.speech.kth.se/snack/man/snack2.2/tcl-man.html#sound - see the formant subcommand.
FFT with pre-emphasis and Hamming window
See above link - the powerSpectrum subcommand.
Power
See above link - the power subcommand.

http://wiki.python.org/moin/PythonInMusic

は？

PUT文がないとゲーム作れないじゃん。
馬鹿言語かよ＞PYTHON

Pythonにはブレースが採用されないから
いつまでたっても糞言語。

ブレースなんてえーだらー

我ながら全くどうでもいい書き込みだ

乳thon

http://news24.2ch.net/test/read.cgi/news5plus/1204187397/

UTF-8で保存されているファイルをEUCに変換したくて次のような症状が出ています
元ファイルに含まれている「髙」という文字のところで止まってしまうようです
(この文字がなければ正常に変換出来ました)

最初はこちらを試しました
ifp = open(src, 'rb')
ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
ofp.write(ifp.read().decode('utf-8'))

UnicodeEncodeError: 'euc_jp' codec can't encode character u'\u9ad9' in position
163: illegal multibyte sequence

その後こちらも試しましたが却って訳が分からなくなりました
ifp = codecs.getreader('utf-8')(open(src, 'rb'))
ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
ofp.write(ifp.read().decode('utf-8'))

UnicodeEncodeError: 'ascii' codec can't encode character u'\u9ad9' in position 1
63: ordinal not in range(128)

どう書けば正しく変換出来るのでしょうか？

ifp = codecs.getreader('utf-8')(open(src, 'rb'))
ofp = codecs.getwriter('euc-jp')(open(dst, 'wb+'))
ofp.write(ifp.read().encode('euc-jp'))

これもだめでした

>>131
あきらめろ

hoge = u'髙'
print hoge.encode('euc-jp')

UnicodeEncodeError: 'euc_jp' codec can't encode character u'\u9ad9' in position 0: illegal multibyte sequence

Pythonではしごだかをどう扱うよって話だね
どういう対処法があるのかｗｋｔｋ

python固有の問題でもないと思うが、
hoge.encode('euc-jp', 'replace')でもしとけば

>>131
UTF-8では表せるけどEUC-JPでは表せない文字というのが山ほどあって
はしごだかはそのひとつ。完全には変換できないです。

読み書きしているファイルが実は HTML や XML だとしたら
xmlcharrefreplace エラーハンドラが便利かも。

>>> import codecs
>>> ifp = codecs.open("input.txt", "r", encoding="utf-8")
>>> ofp = codecs.open("output.txt", "w", encoding="euc-jp", errors="xmlcharrefreplace")
>>> ofp.write(ifp.read())
>>> ifp.close()
>>> ofp.close()

>>136
ビンゴです
ありがとうございました

しかし「～」はEUCにもあるのに「～」になってしまう副作用が出ますね・・・

EUCにコードが無い訳じゃないんだよなぁ
fuga = '\xa1\xc1, \xfc\xe2, \xf9\xf5'

>>137 の2つ目の「～」は「～」でした
読みにくくてすみません

「～」は統一されていない
ttp://ichi.mo-blog.jp/tedious/2007/05/
ttp://www.mysql.gr.jp/mysqlml/mysql/msg/12432

ttp://ja.wikipedia.org/wiki/%E6%B3%A2%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5

ここの「UNICODEに関する問題」を見ると泣けてくる

これみて自分で変換するしかないでしょうね
http://www.ajisai.sakura.ne.jp/~dindi/chrc/ref/wincode2.txt

>>142
いただいた

>>137
「～」はEUC-JPとUTF-8を相互変換するときのテーブルがOS/言語ごとに違うために
変換できなかったり違うグリフで表示されたりします。

俺はよく使う文字について以下のようなコードでWindows用にそろえてます。

    unification = {
        0x2014: 0x2015, # HORIZONTAL BAR
        0xFF5E: 0x301C, # WAVE DASH
        0x2225: 0x2016, # DOUBLE VERTICAL LINE
        0x22EF: 0x2026, # HORIZONTAL ELLIPSIS
        0xFF0D: 0x2212, # MINUS SIGN
        0xFFE0: 0x00A2, # CENT SIGN
        0xFFE1: 0x00A3, # POUND SIGN
        0xFFE2: 0x00AC} # NOT SIGN

    text = unicode(...).translate(unification)

136の例では ifp.read().translate(...) とすればよいと思われ。

ごめ、訂正。Windows用にそろえてるんじゃなくて、PythonのEUC-JP/Shift_JIS/ISO-2022-JPコデックが
受け付けるコード値に置換してる、というのが正しいです。

ついでに説明しとくと144のunification（辞書）は、キーはWindowsで日本語入力したときに使われるコード値、
各キーの値はPythonの日本語コデックが受け付けるコード値です。

この8個の文字にOS/言語ごとの変換テーブルの違いが集中しているので、
144の置換をしておくと UTF-8 → EUC-JP/Shift_JIS/ISO-2022-JP 変換時のエラーがだいぶ減るはず。

蟻が十匹

ありがとうございました

ひょっとして梶●さんですか？

hoge = {'a': 4, 'c': 2, 'b': 9}

for k,v in hoge.items():
print k,v

for k,v in hoge.iteritems():
print k,v

なにがちがうんでしょうか？

ここは質問スレではないんだが

>>> hoge = {'a': 4, 'c': 2, 'b': 9}
>>> type(hoge)
<type 'dict'>
>>> type(hoge.items())
<type 'list'>
>>> type(hoge.iteritems())
<type 'dictionary-itemiterator'>

（´∀｀）ノhoge = dict(enumerate(xrange(1000000)))

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> a
{'hige': 'hage', 'hoge': 'fuga'}
>>> b = str(a)
>>> b
"{'hige': 'hage', 'hoge': 'fuga'}"

ここで文字列 b から hash を復元して
c (= {'hoge': 'fuga', 'hige': 'hage'}) を作りたいのですが
どのように書けばよいでしょうか？

>>> eval(b)
{'hige': 'hage', 'hoge': 'fuga'}

Pythonのアンチスレは質問スレになる不思議

>>152
pickle も調べてみる価値がある、かもしれない
オブジェクトをファイルに保存/復元できるライブラリだよ

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> import pickle
>>> pickle.dumps(a)
"(dp0\nS'hige'\np1\nS'hage'\np2\nsS'hoge'\np3\nS'fuga'\np4\ns."
>>> pickle.loads("(dp0\nS'hige'\np1\nS'hage'\np2\nsS'hoge'\np3\nS'fuga'\np4\ns.")
{'hige': 'hage', 'hoge': 'fuga'}

そのまま書き出すとこんな感じ？
(dp0
S'hige'
p1
S'hage'
p2
sS'hoge'
p3
S'fuga'
p4
s.
読みやすいといえば読みやすいし
JSONやYAMLに比べると微妙なんだけど
このフォーマットって何か由来あるんですか

pickleは人間が編集するようなものではないでしょ
フォーマットは pickle.py, pickletools.py あたり?

FORTHっぽいね

>>153
python はこれができるからいいんだよね、
昔 perl でこれと同じ関数を2週間ぐらいかけて作ろうとしてた時に、(リファレンスやら再帰やら使って・・・）
python は両方builtin でできると知って、一気にperl 捨てたｗ

>>> a = {'hoge': 'fuga', 'hige': 'hage'}
>>> '%(hoge)s' % a
'fuga'

とか、

>>> b = {'moge': a}
>>> '%(moge)s' % b
"{'hige': 'hage', 'hoge': 'fuga'}"

とかは便利なのは分かったんですが、

>>> '%(moge[hoge])s' % b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'moge[hoge]'
>>> "%(moge['hoge'])s" % b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: "moge['hoge']"

ネストされたhashへのアクセスは出来ないんでしょうか？

出来ない

>>160
代わりにこの辺のTemplate使ってる
ttp://pythonpaste.org/tempita/

>>161-162
ありがとうございました
おかげでなんとかなりそうです

ほのぼのとしたアンチスレだな。

ともすると本スレのほうが殺伐としていて困る

pythonはとっとと、ソート演算子のオーバーライドをサポートしてくれ。

演算子?

組み込みクラスの__cmp__()を変更したいとか？
組み込みクラスはオーバーライドできない実装を受け入れて
サブクラス化するなりして問題解決した方が精神衛生上よい。

>>166
引数でラムダ式渡すのでは困る理由は何？

c++ やcommon lispに比べたらモジュールがいろいろ足りない
統計とか数式処理とか
今のままでも便利なんだけど歴史が浅いからね

>>170
scipyとか

C++は老害言語。

老害か。

N88Basicのことかな

> c++ やcommon lispに比べたらモジュールがいろいろ足りない
スクリプト言語では Perl が一番揃ってそうだな
次が Python かな

>>174
>スクリプト言語では Perl が一番揃ってそうだな

数はあるが、玉石混淆で使えるモジュールを選ぶのが大変なのがPerl。

ほしゅ

age

おまいら、py3kについてはどう思うよ？
俺はclassic style classが使えない時点で見放したが。

どんな書き方ができなくなって嫌だったの？

単純な書き換えだったら、2to3ツールって言うので自動で変換してもらえるはず

互換性の無いバージョンだと前からアナウンスしてるんだから、
不要なものはどんどん廃してもらわんと逆に困る。

後にPerl6と揶揄されるバージョンであった

Perl6と違ってちゃんと予定日が決まってるようだが。

つ4/1

そういやParrotって四月馬鹿が発端なんだよな。

AprilFoolを字面通り四月馬鹿と言うのは誤訳？

伝統

intとlongの処遇で、現行バージョンと3kの両方で動くようなソースは事実上書けない。
new style classと違って、こちらは突然のdeprecateになる。

たしかu""やexcept文の,とかも3kでは駄目だったよね

Cで書かれたエクステンションはもっとひどい影響を受けるよ。

互換性切るって言ってるんだから別ソースにしようぜ

Python支持者の隠れ家スレってこちらですか。

そうなんですのよ奥さん
なんかのらくらと、まったり批判及びフレンドリーな雑談で収まってます

表立ってPython批判する奴って少ないんだよなあ。
批判する点も、「ああ、そこ欠点ってわかってますから」というところ
ばかりだし。

Guidoのやり方が上手なんだろうね。

自分の読みたい本を紹介しろということをクエストっていうのか?

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, os, stat
import time

def main(root):
  dirsize = {}
  for dirpath, dirnames, filenames in os.walk(root, topdown=False):
    dirsize[dirpath] = 0
    for file in filenames:
      tgt = os.path.join(dirpath, file)
      siz = os.stat(tgt)[stat.ST_SIZE]
      dirsize[dirpath] += siz
    for dir in dirnames:
      tgt = os.path.join(dirpath, dir)
      siz = dirsize[tgt]
      dirsize[dirpath] += siz
      print '"dir","%s",%d' % (tgt, siz)

  print '"total","%s",%d' % (root, dirsize[root])

if __name__ == '__main__':
  if len(sys.argv) >= 2:
    main(sys.argv[1])

これでちゃんと動いていたような気がしたのですが
検索パス中に　▽●▲表　みたいな \5C で終わる
ディレクトリが含まれていると中断されてしまいます。
たぶん日本語の問題だろうと思って

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, os, stat
import time

def main(root):
  dirsize = {}
  for dirpath, dirnames, filenames in os.walk(rootroot.decode('cp932'), topdown=False):
    dirsize[dirpath] = 0
    for file in filenames:
      tgt = os.path.join(dirpath, file)
      siz = os.stat(tgt)[stat.ST_SIZE]
      dirsize[dirpath] += siz
    for dir in dirnames:
      tgt = os.path.join(dirpath, dir)
      siz = dirsize[tgt]
      dirsize[dirpath] += siz
      print '"dir","%s",%d' % (tgt, siz)

  print '"total","%s",%d' % (root, dirsize[root])

if __name__ == '__main__':
  if len(sys.argv) >= 2:
    main(sys.argv[1])

のように直したら中断はされなくなったのですが、
hoge.py . > fuga.csv
で保存しようとするとエラーになります。
(上のバージョンはリダイレクトは出来ていました。)
Python の日本語の扱いが良く分かりません。
Python 嫌いになりそうです。＞＜

後から貼った方が何か変なので直しておきます。

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, os, stat
import time

def main(root):
dirsize = {}
for dirpath, dirnames, filenames in os.walk(root.decode('cp932'), topdown=False):
dirsize[dirpath] = 0
for file in filenames:
tgt = os.path.join(dirpath, file)
siz = os.stat(tgt)[stat.ST_SIZE]
dirsize[dirpath] += siz
for dir in dirnames:
tgt = os.path.join(dirpath, dir)
siz = dirsize[tgt]
dirsize[dirpath] += siz
print u'"dir","%s",%d' % (tgt, siz)

print u'"total","%s",%d' % (root, dirsize[root])

if __name__ == '__main__':
if len(sys.argv) >= 2:
main(sys.argv[1])

>>197
× rootroot.decode('cp932')
○ root.decode('cp932')

>>198
エラーにならん。
traceback張れ。

検索パス中に日本語が入っていて
hoge.py c:/ > fuga.csv
で保存しようとするとエラーになります。

これとか？

http://python.rdy.jp/wiki.cgi?page=%C6%FC%CB%DC%B8%EC

site-packageディレクトリにsitecustomize.pyを設置して、文字コードを指定する。

sys.setdefaultencoding('cp932')

>>198
KeyErrorで止まるのならこれで動くんじゃないかと
decode()の呼び出しで無駄が多いから調整してね

print '"total","%s",%d' % (root.decode('cp932'), dirsize[root.decode('cp932')])

ていうかここアンチスレか

>>201
だからエラーの内容貼れって

encodeしてないだけだろ

>>196-201
なにこの大富豪的プログラミングｗ
メモリ喰いまくってるだけで全然終わらないしｗ

よくわからんが、os.walkをやりたいだけか？
http://docs.python.org/lib/os-file-dir.html

>>197
> Python の日本語の扱いが良く分かりません。
> Python 嫌いになりそうです。＞＜

標準出力がリダイレクトされていない場合、Python の print 文は
与えられた Unicode 文字列を自動的に cp932 等の実行環境固有のエンコーディングで
エンコードして印字するようになっている。これは Python インタプリタを
対話的に利用するときには便利な仕組みだ。「実行環境固有のエンコーディング」が
具体的に何であるかは sys.stdout.encoding を見れば分かる。

一方、標準出力がファイル等にリダイレクトされている場合、
どのエンコーディングで文字列をエンコードすべきかを決めるのは難しい問題だ。
cp932 がいいかもしれないし用途によっては utf-8 や iso-8859-1 の方がいいかも知れない。
つまり、Python の立場からは標準出力をリダイレクトする場合のエンコーディングを
これと決めることができない。このことは、標準出力をリダイレクトしているときには
sys.stdout.encoding が None になることから分かる。

この場合、print 文は sys.stdout.encoding の代わりに sys.getdefaultencoding() が返す
エンコーディングでエンコードして出力する。このエンコーディングは Python の出荷時の
設定では ascii になっているので、日本語等を含む Unicode 文字列を print しようとすると
実行時エラーになる。

結局のところ、標準出力をファイルにリダイレクトできるようにプログラムを書くには
sys.stdout.encoding による自動エンコードに頼らないようにしなければいけないということだ。
個人的には、Unicode 文字列をファイルなり標準出力なりに書き出すときは
明示的にエンコードするように心がけるべきだと考えている。暗黙の自動エンコードに
頼るとロクなことがない。

じゃあ具体的にどうすればいいのかという話だけど、お勧めは次の方法だ。
まず次のように標準出力を適当なエンコーダで包む。

import codecs
Writer = codecs.getwriter(sys.getfilesystemencoding())
stdout = Writer(sys.stdout)

その上で print 文をすべて次のように書く。

print >>stdout, '"total","%s",%d' % (root, dirsize[root])

この例ではリダイレクトしているか否かに関わらず sys.getfilesystemencoding() の返す
エンコーディングでエンコードするようにしている。このエンコーディングは、俺の知る限り
標準出力がリダイレクトされていない場合の sys.stdout.encoding と一致している。
sys.getfilesystemencoding() を使う代わりに、例えば cp932 に決めうちしちゃうとか、
コマンドライン引数で出力エンコーディングを指定するようにするといった方法も考えられる。
標準出力リダイレクト時のエンコーディングをどうするかは用途に強く依存する問題なので
こればかりはプログラムを書く人（つまり197さん）が決めるしかない。

>>209
u'"total","%s",%d'じゃない?

ごめん、勘違いしてた
str % unicode はunicodeになるからいいのか

>>211
その辺がマンドクセなんでp3kではbyteとunicodeのみになるんだろうな。

>>210-211
確かに u"・・・" にすべきだった。指摘ありがとう。

一般論としては u"・・・" にする必要があるかどうかは文字列の中身に依る。
例えば u"・・・" ではなく "・・・" を使って日本語で
print >>stdout, '"総計","%s",%d' % (root, dirsize[root])
としたら % 演算子の処理のところで暗黙の string → unicode 変換が起こる。
ソースのエンコーディングと sys.getdefaultencoding() の値によってはエラーになるわけだ。

文字列の中身が ASCII 文字だけなら暗黙の変換が起こってもまず問題ない。
ただ、無駄な変換ではあるし、暗黙の自動変換を避ける方針でやりましょうと言ってる
わけだから、やはり u"・・・" にするのが妥当だ。

というわけで>>209を訂正：

誤：　print >>stdout, '"total","%s",%d' % (root, dirsize[root])

正：　print >>stdout, u'"total","%s",%d' % (root, dirsize[root])

print文はデバッグ用です。異論は認めない

逆に、printをデバッグ用に使う奴はダメだろ。

デバッグのつもりが余計に訳分からなくなる罠ｗ

0100
とすると
64
と表示される。
8進数なんて誰も使わんわ。
危ないからやめてくれよう

二進数表記が欲しいなーと思ったことはあったような無かったような

>217
Python3.0から8進表記は0o777のようになるとか

>218
同じく0b1101とかでできるようになる

>>219
thx
どっちも覚えやすくていいね

>>208
ありがとう

こないだC++0xスレで二進表記ネタで喧嘩してたな。
いわく、二進表記は「馬鹿がする馬鹿な要望」と。

0b1101

0x0D にすべきか 0xFD にすべきか

>>223
0xffは256なのか、それとも-1なのか。
それと同じでいいんじゃね？

>>224
256じゃなくて255だった。orz

代入する先の変数の型がbyte以外は0xFDで良いと思う

>>223
0xdは13なのか、それとも253なのか。
それがわかれば、そんな愚問に悩む意味はないだろ。

>>226
Python の変数には型はない。

2の補数とかバイト数とか、どちらかといえばハード側の概念を
わざわざ持ち出す理由はないような

表現って概念に疎いんだろうな

リテラル周りは、煩雑になりがちだから、あんま記法は増やさないでほしい。
というか、その言語の持ってる特徴がよくわかる所だよな… >リテラル周り

うにコードや円光度は暗黙に適当に変換してくれて
必要なときだけ確定するのと同じようになればいいよ

>>232はi18nで困ったことがないんだろうな。全部sjisで決め打ちなんじゃね？

MS屋さんはMSがいろいろ面倒をみてくれるのでお気楽です
MSDNを漁る苦労は真似したくないけど

うーんガンダム

二進表記はいらんけど、
メガバイト単位のながーいビット列を
自在にあやつるモジュールが欲しいざんす。

簡単だから自作汁

入門書のお勧めたのむ！

http://www.python.jp/doc/release/tut/

ありがとう。
でも、喫茶とかで読みたいので、
本でよろしくです。

http://www.oreilly.co.jp/books/9784873113678/

マジお勧め

http://www.oreilly.co.jp/books/9784873112763/

こっちだろう

http://www.amazon.co.jp/dp/4886487602/

もったいぶって済まなかった。これがファイナルアンサー。

>>243
出版社潰れてるよ。
この本の著者はきっと呪われているね。

初版はまともに校正されてなかったし
それ以前からやばかったんじゃないの？

やばい出版社が執筆依頼するやばい著者ってことか。
出版社も著者も五流だったんだな。

出版社が潰れるとは切ないな……

この著者は前に自分の会社も潰してるね。
のろわられてるとしか思えないね。

>>238ですが。
クックブックの訳注いわく、Pythonは
入門書がいらないくらい言語が簡単なんで
リファレンスを少しみてから俺の本を買えとの事です。

どうりで、(個人的に合わず)おかしな入門書が多いわけです。
>>239のリファレンス、>>242とすすみます。
皆様どもでした。
※言語が簡単ということは、守備範囲が狭いとも
とれるが、価値がある言語か不安であるｗ。

正直、インスタントとチュートリアルで足りる。
Webアプリもmod_pythonのチュートリアルで足りるし。

>>※言語が簡単ということは、守備範囲が狭いとも
>>とれるが、価値がある言語か不安であるｗ。
おまえそれlisperに言ってみろ

>>249
何でそんなに偉そうなんですか

偉そうなつもりはないです。

言語のシンプルさと応用範囲の広さは別に相反しない。
充実したライブラリの整備や周辺技術の展開が可能な程度に柔軟性があれば。
言語の応用範囲はその言語に関わる人的資源に恵まれるかどうかにかかっている。

PHP：PEAR、Zend Framework
Perl：CPAN
Java：Jakarta
が有名ですね。

言語環境に、Class、StackTraceとかないと
面倒だよね。

>>255
何が言いたいのか分からんけどPythonはその辺はカバーしてるでしょ

>>248
「実践Python」ってそんなにすごかったのか(www

ttp://www.amazon.co.jp/dp/4886487602/

sqlite3の項は必読ですよ
立ち読みして吹いて買取りさせられても知らないってぐらい

変な奴が沸いてるなと思ったがアンチスレだったな

本スレ？が潰れたのはアンチのせい？
それとも夏のせい？

>>260
今、報告の準備してる。
落ち着いたら報告する。

>>260
Ruby批判したせい

↑犯人が戻って来たようです

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

アンチ板への妨害って信者ってことですか。
といってみる。

Python恨まれすぎ

Ruby厨房の仕業ですか

Pythonスレの荒らし、俺の予想
2007年 6月２ちゃんねるを本格的に始める
　　　　 6月過去ログが見れないことに腹を立て●を購入
　　　　 12月 VIP初体験
2008年 8月3日 IDが簡単に変更できることを知る
　　　　　　同日東方シリーズ総合スレッドを荒らす
8月4日マクロを使って本格的に荒らす
　現在　ム板で個人的に気に入らないPythonをスレを潰しにかかる

ちょっと実践Python立ち読みしてくる

いまさらで良いので誰か
　Pythonを256倍使いこなす本～愛多憎生編～
とか書いてよ。

256倍シリーズはどうもあの真ん中に大きな字で何度も強調するスタイルが嫌だ

あれがなかったら256本じゃないだろ

あれを抜いて2.56倍本を...

256倍シリーズはC以外おもしろくなかった

AWK本は名著

うむ

アンチスレ平和すぎだろ

Time flies like an arrow.

>>382
安置

３．０が思ったほど遊べなくてガックリ。
互換性をきるなら、もっとババーン、キャーみたいなのやってくれれば良いのに。

Python系でも後発Booとか見ると結構いい感じなんだよな
defで匿名関数定義できてPythonのlambdaみたいな制限もねーし
Lispのマクロみたいなノリでメタプログラミングっぽいことも出来るみてーだし

後、Pythonは常にselfとか書かせるぐらいなら、束縛と代入で
:=, =みたいに構文分けるかletとか書かせるようにして欲しかった
ミスに弱いし、global文とかnonlocal文とか場当たり的で醜いよ

そうだね

Booは名前がなあ
いくら中身が良くても名前だけでやる気が起こらないって恐ろしい

どういうやつ？
取り込み中なんで、あとでくわしく

取り込みは終わりましたか？

:=, =

アンチではないけど、
Python ドキュメント(Python ライブラリリファレンス等)が
どうも見難くてたまらん。

そうだね
あれじゃ目的のものにたどり着けないよね

Pythonのドキュメントは愛がたりない
Rubyみたいなドキュメントになってほしい

未完成な「Rubyリファレンスマニュアル刷新計画 chm版」というのを
ダウンロードしてみたけど、Rubyのほうがちゃんと気合い入ってそうだ。

>>392
http://docs.python.org/search.html?q=defaultdict

2.6系からドキュメントシステムが変わりました…
Json のindexを構築して検索してるそうな…
sphinx + Pygments とかでぐぐると嬉しい
http://sphinx.pocoo.org/

左側の無駄なスペース無くして欲しいんだが
それにフォントもでかくなってて読みにくい
使い勝手は良くなったのかも知れないが
生理的に受け付けなくなりつつある

もっとサクサク動くようにするべきだと思う

オライリー本のヘビの絵がきもい。

Twisted本はさらにひどい。
しかしそれはオライリーに文句を言うべき

>>397
俺もそれはウザいと思っていたのでスタイルシート弄った

前は気軽にプリントアウト出来てたのに

>401
こういう時、ユーザスタイルシートって有難いな

>>397
>左側の無駄なスペース
目次用のエリアじゃないのか？

pythonは速いと聞いたので覚えようと思ったけど文法が訳ワカメで難しすぎて無理
もっと、こっからここまでをバシっと決めてくれないかなぁ

Cにしとけ

早いのがいいならFORTRANだろ

>>405
Pythonで文法がわかりにくいというのは初めて聞いた
具体的にどこがわかりにくいのだろうか

endがなくてキモい

Pascal信者乙

Pascal 信者であれば begin, end が無いという
Ruby 信者でしょ

行の開始位置が構造に関わるとか
COBOLかFORTRAN並みに古すぎとか
思ってたけど慣れるとなんでもない
endの方がきもい
漏れはRubyでも{}使う派なんだけど
Rubyは{}じゃだめでdo～endでしか書けないケースが結構ありすぎ

>>412
Python型の行頭位置の規則（オフサイドルール）は、
言語の系譜としては現代的なものだぞ。他にHaskellとか。

> Rubyは{}じゃだめでdo～endでしか書けないケースが結構ありすぎ
逆じゃないか？
Rubyの見栄え上do～endのほうが良いなぁと思うのに、{}じゃないと書けないケースが多いと思う

多分個人のコーディングの癖（好むメソッドの組み合わせパターン）で
違ってくると思う。

>>412 書いたの漏れなんだが
なんであんなこと書いたのか
もう思い出せない orz

>>409
end = Noneと書けばendが書けるよ

pass で閉じてる漏れは勝ち組み

>>414
foo hoge {
}
でfooにブロックをつけたいとかいうパターンだろう。
rake絡みなんかでよくある質問だな。

pythonはforが大杉。

安置というより無知を曝すスレだな

pythonスレはアforが大杉

自愛するべき

>>420
for で充分だからブロック構文いらない。

Ruby厨はよく Pythonには○○が無いって叩くけど、大抵そういう機能は
Python-Idea ML で必要・不要が議論された結果不要と判断されている
ので、その機能が無くても同じ生産性をPythonは既に実現している。

for多すぎって[ ]の中じゃないの？

>>424
そうでもないだろ。

Pythonの配列操作がRubyと比べて面倒くさい
ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

それよりPythonはsuperのキモさをなんとかしてくれんかいのう。
なんでsuper()に親クラス名を指定しなきゃいかんの？ba

>>426
multi-inheritence dakara

>>427
多重継承はまったく関係ないよ。
つうかなんで多重継承が関係してくんの？

>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

つ '-'.join(["%s"%(x) for x in sorted(a, reverse=True)])

私Ruby厨だけどsuperに関しては
superとsuper()で引数が違ってくるRubyの方がキモイと思う

>>426
> なんでsuper()に親クラス名を指定しなきゃいかんの？ba

Smalltalk系のようにsuperがcaller側のmethodのbindに依存するほうが
よほど言語設計として汚ないと思うが？

>>431
なんで汚いん?
「親クラス」という抽象的な表現ができず、具体的なクラス名をいちいち書かないといけないことは汚くないの？

明示的なだけで汚くはないだろ
多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
Python3からは引数省略してsuper().methできるらしいけど

>>433
>明示的なだけで汚くはないだろ
明示しなきゃいけないんだから汚いだろー
なんで抽象化されてないのさ

>多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
は？そんなのふつうのメソッド呼び出しでも一緒じゃん

class A(object):
　def f(self): print 'A'

class B(object):
　def f(self): print 'B'

class X(A, B):
　def g(self):
　　self.f()　　　# どの親クラスのメソッド呼ぶのか曖昧なの？ねえPythonってそうなの？

ふつうのメソッド呼び出しで行なっているのと同じルールを使って、親クラスのメソッドを呼べばいいだけじゃん。
もしPythonが本当に『どの親クラスのメソッド呼ぶのかさえ曖昧になる』んだったら、
もうsuper関係なしに、オブジェクト指向言語として失格だろwwwww

>Python3からは引数省略してsuper().methできるらしいけど

やっぱり多重継承関係ないじゃないかwwwww
>>433は２行目で書いたことを３行目で忘れてるおばかさんーwwwww

ようやくアンチスレらしくなって妙にうれしい

>>434
そうだね、だから Python 3.0 では super() に self を明示しなくても良くなるよ。
今の Python は、 Python 2.2 までの古いクラスと新しいクラスが混在していて、
後方互換性の為には明示的にクラス名を書かないといけないの。

古いクラスと新しいクラスが混在って要・不要が議論されたあげくにそれか？
自慢げに語ることじゃないだろ。　よほど言語設計として汚ないと思うが？

2.xまで混在
3は新だけ

>>437
Rubyとちがって、過去の資産を大切にするからね。
後方互換性を切る Py3k も数年がかりのプロジェクトになる。

新クラスは、必要と判断されたから導入された。でも、後方互換性の為に
旧クラスは残されている。
ruby のメソッドチェーンやブロック構文は、Pythonに導入しても「一部の人が
気持ちいい」とか「ときどき数タイプ減らせる」程度の効果しか認められないから
Pythonには導入されない。

>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788
メソッドチェーンになれたRubyistがメソッドチェーンを無いことを反射的に
批判しているだけだろ。

文を分けないで関数を無制限にゴチャゴチャ繋げるのはPythonicではない。
一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
文を分けるべき。文を分けたることによって数タイプ増えるが、その分可視性は
向上するので、トータルの生産性に大きな差は無い。それなら、すっきりした
書き方だけを使うのが Pythonic way.

久々に伸びてると思ったらなんじゃこりゃ

>>432
同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。
言語仕様上の透明性を求めるか、表現式としての簡便さを求めるかの言語仕様上のトレードオフでしょ。

>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

単に初学者が前に習った言語の作法にひきずられて
今学んでいる言語の流儀に逆らってるだけに見える。

rubyやJavaのメソッドチェーン使うときにいつも気になるのは
途中でメソッドの戻り値がぬるぽになるんじゃないかってところ
だからpythonで文を分けて毎回if not hogeしている漏れは勝ち組

>なんか今更この記事にコメントが付きだしたのですが、どこかで紹介されたのでしょうか?
笑える

>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> ttp://d.hatena.ne.jp/edvakf/20090405/1238885788

ruby
a.sort().reverse().map{|x| x.to_s}.join('-')

python
'-'.join(map(lambda x:str(x), reversed(sorted(a))))
'-'.join(str(x) for x in reveresed(sorted(a)))
'-'.join('%s'%(x) for x in sorted(a, reverse=True))

確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？

>>436
なるほど、それが理由なのか。
じゃあ最初にオブジェクト指向機能を導入した時の設計が間違ってたんだな。
とりあえず「多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になる」と言いはるバカは消えろwww

>>439
>Rubyとちがって、過去の資産を大切にするからね。
ちーがーうー、最初の設計が間違っていたから仕方なく過去を引きずっているだけwww
それを「過去の資産を大切に」とかバカまるだしwww
ほんとに大切にするなら3.0でも互換性をとっとけwww

>>442
>同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。

ほんとにそう思う？ほんとにそう思うなら、親クラス名が省略できるようになった3.0は美しくないの？
442にとっては3.0の仕様が美しくないそうだよwwww またバカ丸出しwwwwww
Pythonistaは442みたいなのをだまらせとけやwww 身内の恥さらしだぞwwwwww

雑草が増えたな

>>445
>python
>'-'.join(map(lambda x:str(x), reversed(sorted(a))))
>'-'.join(str(x) for x in reveresed(sorted(a)))
>'-'.join('%s'%(x) for x in sorted(a, reverse=True))
>
>確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？

厳密にひとつ、というわけじゃなくて、だいたい一つ、ぐらいの意味でいいんじゃない？
これくらいだったら十分許容範囲だろ。許してやれよ。

> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')

これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
Python狂信者はこの事実を認めようとしないだろうけど。

>>440
>一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
>文を分けるべき。
それはPython限定の話だよね? 一息に書きにくい言語はそうすべきだけど、
一息にかける言語だったらそんなことに縛られる必要はまるでない。

>> 443
> 単に初学者が前に習った言語の作法にひきずられて
> 今学んでいる言語の流儀に逆らってるだけに見える。
こういうやつがいるかぎりは、争いはいつまでたっても終わんないだろうね。

ある種の若い男の子にありがちな語り口だよね。
わかるまいわかるまいと頑張りつつ、わからせる気も無い、のっけからの平行線狙いって。
場を味方につけつつ展開しないと、単に「こいつ一人が理解力無いだけ」って判断されて
オシマイなんだけど。

one liner書きにくすぎ
インデント氏ね

>>448
> > ruby
> > a.sort().reverse().map{|x| x.to_s}.join('-')
>
> これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
> Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
> Python狂信者はこの事実を認めようとしないだろうけど。

python
'-'.join(["%s"%(x) for x in sorted(a, reverse=True)])

これは全体の処理がトップダウンにきれいに流れるから読みやすいんだよね。
rubyのように処理順にすると最後にならないと全体の仕事がわからずに読み進めなきゃならない。
俺はruby狂信者なんてレッテルを貼ったりしないけど。

>>445
その例だと、一番目は lambda が不要で
'-'.join(map(str, sorted(a, reverse=True))) # もしくは itertools.imap

二番目は reversed が一つ余計で
'-'.join(str(x) for x in sorted(a, reverse=True))

三番目の % 記法を無理やり使うのは無いな。少なくとも (x,) としないと、 x 自体がタプル
だったときに問題が起こる。

>>444
確かに、Pythonの一行 = 1文 = 一つの事　という文化は、
例外発生時にスタックトレースを見るとすぐにどこが例外を
出したか特定できるという副次的な効果もあるねw

>>448
> > ruby
> > a.sort().reverse().map{|x| x.to_s}.join('-')
>
> これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
> Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
> Python狂信者はこの事実を認めようとしないだろうけど。

「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」
左から右なんだよね。なんで代入は右から左のままなの?代入演算子を => に
すれば、
s = a.sort.reverse
s.map{|x| x.to_s}.join('-')
という風に代入が混じっていても、
a.sort.reverse=>s.map{|x| x.to_s}.join('-')
って書けるのにさ。
結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
とか言っちゃってる気がしてならない。

あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
どうなんだ? Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという
方が分かり易いし正しいと思うぞ。

末尾に!を付けると代入になるとかいいんじゃね

>>454
「左から右」が好きなのは最近の人っつかRails厨に多い気がする
(s = a.sort.reverse).map{|x| x.to_s}.join('-')で別に気にならないな
理屈は後付けで結局Matzの思いつきが多いのは然りごもっとも

> あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
num.to_sとかの延長で考えると、別にいいんじゃねと思ってる
機能よりは主体がどっちなのかで分けてる感じかな、よくわからんが

*リスト*を連結するのがstrのメソッドなのはいいのか？

リストの連結（リストをいくつか受け取って連結したリストを返す）メソッドがstrに定義されてる
言語なんてあるのか？

>>444
がっ!

>>453
それはたまたま副次的な効果が出たんじゃなくて
効果を期待してそのために文を分けてると思ってたｗ

> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')

これ成城に動いてるときはいいんだけど
バグが出たら何が原因か分かりづらいぜ？

>>454
>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。

そういう理由だったの？
Smalltalk から影響受けたんだと思ってたお

>>457
リスト以外でも、イテレートできればなんでも連結できるよ?

>>454
>「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」左から右なんだよね。
なんですべてを左から右にしようとしてんの？別に右から左でもいいけどさ、個々の処理がきれいに流れていることが重要なんじゃん。
unixのコマンドラインでパイプを使って処理を連結する感覚と一緒。Pythonとかだとそれがないってだけ。

>なんで代入は右から左のままなの?代入演算子を => にすれば、
>s = a.sort.reverse
>s.map{|x| x.to_s}.join('-')
>という風に代入が混じっていても、
>a.sort.reverse=>s.map{|x| x.to_s}.join('-')
>って書けるのにさ。
そんなふうに書くわけないじゃん。
(s = a.sort.reverse).map{|x| x.to_s}.join('-')
でいいだろ。自分で書いてて気づかないのか？

>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。
いや実際読みやすいだろ。

>あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのはどうなんだ?
連結した結果として文字列以外になんかあるか？joinは*要素を連結して*文字列として返すメソッドなんだから、リストのメソッドで何にもおかしくない。

> Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという方が分かり易いし正しいと思うぞ。
戻り値が文字列だからといって、要素を連結する機能を文字列に関する機能と考えるほうがどうかしてる。
joinはあくまで「要素を連結する」ためのメソッド。リストのメソッドで何が悪い。

>>452
おれもlambda x: str(x) とか書いてた！これはいらないのか！ちょー参考になった。さんくす。

>>458
Java

python は lisp と謂われる所以ですな

>>452
今回はたまたまそれで良かった訳だが
str() 以上に複雑なことさせようとしたら lambda 必要になるよね？

理想ばっか語ってても仕方ないよ

>>464
例えば、xhtml を動的に生成する場合、
data = [tag.P(t) for t in "foo bar baz".split()]
contents = tag.HR.join(data)
print str(contents)
で、
foo
<hr/>
bar
<hr/>
baz
とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
文字列処理にしか出てこないとは限らないだろ。

>>467
それ以上に複雑になったら、mapではなくてリスト内包を使う。
リスト内包でもすっきり書けないくらい複雑になったら、ローカルで関数を定義して
それを map する。

Pythonの関数は普通の変数と同じ名前空間に存在しているので扱いが楽。

>>464
> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
処理しているんだよね?

俺は「左から右」のメソッドチェーンがPythonicな書き方に比べて特に
読みやすいとは思わないけど、もし「左から右に流れるように処理が連結
できる」のが本当に読みやすいのであれば、代入式も代入結果が式の値
なんだから代入結果を右に持っていくべきだよね。

Ruby厨ってRubyこそ正義って思って思考停止してない?

pythonのlist.sort(), list.reverse()が処理後のリストを返さない理由を2文字で教えてください。

>>471
464ではないし、Ruby触ったことないけど・・・
それは「コンピュータが処理をする順序の話」に寄りすぎちゃってない？
これって、「人間が動作の流れを目で追う話」だよね？

俺が「一人の人間として」コードがやっていることを目で追うとき、
代入というのは「○○に××を代入する」行為であると捉えているから、
このコードは十分「左から右」になってるなぁ。
sにaをソートしてひっくり返したものを代入して、mapしてjoinする、って読む。

>>470
mapとリスト内包ってどっちが速いん？
メモリ使用効率は？

代入を右から左に「読む」という主張の人は、当然ながら
a = b = c = 10
みたいなコードは、「10をcに代入し、その値をbに代入し・・・」って読み方なんだよね。
俺はそうじゃなくて、「aとbとcに10を代入する」って読む。

この認識が「コンピュータの動き」と異なっていることはわかっているけど、
でも自分が「プログラムの動き」からも離れて強引に左から右に読んでる、とも思わない。

>>471
>> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
>これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
>そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
>処理しているんだよね?

いや、最初に「(s=」が目に入るからその時点で
脳内スタックに s の代入と s に対する次の
「).map」の準備が出来るから大丈夫

Pythonのjoinが文字列のメソッドとなっているのは、単にリストだけでなくタプルや文字列やジェネレータのように
繰り返し可能なものすべてを扱えるようにしているからだよね。

だからほんとは
join(iteratable, separator='')
という関数でよかったんじゃないの？
joinが文字列のメソッドだからすごく違和感があるけど、単なる組み込み関数として存在するなら、別に違和感なし。

join(['a', 'b', 'c'])
join(('a', 'b', 'c'))
join(x for x in 'abc')

>>465
Javaのどのメソッド? Stringクラスにはないけど。

(s = a.sort.reverse).map{|x| x.to_s}.join('-')
これを代入部分も含めたメソッドチェーン的に書き直すなら
s.assign(a.sort.reverse).map{|x| x.to_s}.join('-')
だろうね

>>472
ヒントください

>>469
>シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
>文字列処理にしか出てこないとは限らないだろ。
だったらなおさら文字列のメソッドにするべきじゃないだろ。
セパレータは文字列と限んないんだろ？joinを文字列のメソッドにしたら、セパレータは文字列限定じゃないか。
join(seq, sep='') のような組み込み関数にしとくべきだろ。
''.join()が文字列しか対象としてないのを忘れて「文字列処理にしか出てこないとは限らない」とかバカじゃねーの

map が map(func, list) の構造をしてるから
join(sep='', seq=[])
になってた方がいいかな

それどこのreduce

join = lambda x, y: y.join(map(str, x))

すべてS式にすれば争いは起きないのに

>>485
すべてS式にしたらしたでCLOSになって、
どれがマルチメソッドの第一引数になるかで揉める予感。

>>472
in-place なメソッドだから。

>>477
文字列に限定しないメソッドにする場合、まず　「つなぐ」　が何かを
定義しないと行けない。join を処理前の iteratable と切り離すのは
全く問題ないが、つないだ後の形と切り離して扱うのは効率が悪い。

>>481
セパレータの型によってjoinの実装が変わるんだから、
文字列以外でjoinするときにはその型が自分でjoinを実装するべき。

>>469
Python標準では str 以外で join() を実装しているのってあるの?
hogehoge.join(['a','b','c']) # hogehoge は何か
文字列以外の join() が用意されてないなら、469のは説得力を感じないなあ。

>>490
少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
名前はスレッドの join であったり db の join であったりたくさんあるよ。

逆に、 str.join だと何か問題があるの？グローバルという特別な空間を
犯したり、リスト・タプル・その他すべてのイテレート可能型の名前空間に
文字列のための "join" メソッドをねじ込まないといけない理由は何？

>>491
>少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
>名前はスレッドの join であったり db の join であったりたくさんあるよ。
意味の違うjoinをもってきてどうすんの？
今は hogehoge.join(seq) の形でリストやタプルを引数にとるものの話にきまってるだろ。
だれがスレッドのjoinの話をしてるの? Threadのjoinはlistに実装すべきだとかだれかいったの？

話をすりかえんなよ。元の話は "".join(list) より list.join("") のほうが自然かどうかという話だろうが。
listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
そこをおまえがセパレータが文字列じゃないjoin()もあるとか言い出したんだろ。
だからセパレータで文字列を使わないjoin()や、文字列以外での連結を行うjoin()は実際にあるのかと聞いたら、スレッドのjoinを挙げるなんて、バカすぎるわ。
リストやタプルの要素を連結する話なのに、スレッドやDBが関係あるわけないだろ。
「文字列以外の場合も考えられる」といっているけど、結局は具体例挙げられなくて、苦し紛れにjoinがつくものを挙げただけじゃんか。

おまえ反論したいだけだろ。「多重継承があるからsuperにはクラス名が必要」とか、いちいち理由をねつ造すんなよ。
つうかPythonistaはこんなやつほっとくなよ。Python界の恥さらしだろ。身内の恥は身内でなんとかしてくれ。

>>492
お前こそ反論したいだけだろ。
>>491 は UserString という「同じ意味の」 join の反例を出している。

その上で、文字列以外にも join という名前はよくでてくるから文字列と
直接の関係がないリストに join という名前で文字列用のメソッドを
持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。

RTFM
ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

>>492
> listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
joinはlistの要素を連結するんじゃないぞ。iterable であれば tuple でも generator でも
なんでも使える。listのメソッドにしたらリストにしか使えない。これだけでもリストに join を
実装すべきでない明確な理由になるな。

>>490
> Python標準では str 以外で join() を実装しているのってあるの?

unicode.join()
bytes.join()

>>496
bytearray.join もだねw

Python FAQにjoinのこと載ってあった。

4.8 Why is join() a string method instead of a list or tuple method?
(なんでjoin()はlistやtupleのメソッドじゃなくてstringのメソッドなの?)
ttp://www.python.org/doc/faq/general/#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

やっぱりみんな疑問に思うよな。思わないやつもいるけど。

FAQの答え
This method can be used with any argument which obeys the rules for sequence objects, including any new classes you might define yourself.
(このメソッドは、シーケンスオブジェクトのルールに則った引数なら何でも使うことができます。あなた自身が定義した新しいクラスでも構いません。)

つまりlistやtuple以外でも、sequenceのように振る舞うものなら何でもjoinできるようにするために、joinをlistではなくstrのメソッドにしているわけだ。
>>477の通りだな。

Rubyだとmix-inがあるから、任意のクラスでEnumerableをincludeしてやればArrayじゃないものでもjoinが使えるようになるけど、
Pythonではそうするかわりに引数を抽象化することで、繰り返し可能であればなんでもjoinで使えるようになるということか。
これならjoinがstrのメソッドである理由として納得できるな。
Pythonでは多重継承できるんだからMix-inも使える。だからEnumerableを導入することは技術的には可能だけど、iteratableを引数にするという方法も悪くないね。

これでスッキリした。Pythonいいね!
あとは多重継承が～、joinは文字列を対象にしたメソッドだから～、と、間違った理由をねつ造するバカを排除してくれ。
ほんとの理由を知らないくせに、分かったふりして語るなよな。答えしらないんなら出てくんな。
おまえリアルでも知ったかぶってるだろ。ほんと迷惑。

なんでここIDでないんだろ

迷惑な香具師に絡んで空気汚す香具師も迷惑

>>493
>>>491 は UserString という「同じ意味の」 join の反例を出している。
なんでこれが反例なんだ？要素を連結して文字列を返しているんだからstr.joinとかわらない。
反例というなら、文字列じゃないセパレータを使って、要素の連結結果として文字列じゃないのを返すものをだせよ。

>その上で、文字列以外にも join という名前はよくでてくるから文字列と
>直接の関係がないリストに join という名前で文字列用のメソッドを
>持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。
だから、「joinが文字列用のメソッド」といいきれるのかという質問の答えになってないだろ。
おまえの話は、「joinは文字列用のメソッドであるのが自然」という前提から始まってるだろ。
その前提がおかしいんじゃないかって話をしているのに、名前空間なんか関係ないだろ。
はなっから質問が理解できてねーwww

>>495
そういう納得できる回答がほしいわけよ。バカのねつ造にゲンナリしたから、もう自力で探したけど。
バカが理由もなく「joinは文字列用のメソッド」とかぬかしてるから、Rubyistごときに反論されるんじゃん。

ついでにいうと、それはjoinがlistやtupleのメソッドではない理由としては十分だけど、strのメソッドである理由としては不十分だけどな。

あとsuperでクラス名を指定しなきゃいけないのは、多重継承が原因じゃないからな。試験にでても間違えるなよ！

>>498
一つの理由を見つけただけですべてを判った気になるな。
ちゃんとそのFAQの最後に、
Because this is a string method it can work for Unicode strings as
well as plain ASCII strings. If join() were a method of the sequence
types then the sequence types would have to decide which type of
string to return depending on the type of the separator.
って書いてあるだろーが。

>>477,495 が正解であると同時に、「strのjoinだからstr.join」というのも
正解だ。

Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
join_to_mystr なんてメソッドを Enumerable に追加するのか?
似たものを追加するときに同じ方法を一貫して使えるのが
正しい方法だ。

>>461
>> ruby
>> a.sort().reverse().map{|x| x.to_s}.join('-')
>
>これ成城に動いてるときはいいんだけど
>バグが出たら何が原因か分かりづらいぜ？

Python:
'-'.join(str(x) for x in sorted(a, reverse=True))

Pythonだって、バグが出たら同じようなもんじゃん。

>>501
> なんでこれが反例なんだ？
> 要素を連結して文字列を返しているんだからstr.joinとかわらない。

strを拡張した型を作って join() したら元の str に戻ってしまうのが
正しい動作だと言うのか?
Unicodeをjoin()した結果がstrになるのが正しい動作か?

同じFAQに、
"1, 2, 4, 8, 16".split(", ")
が
", ".join([1,2,4,8,16])
と対称性が取れているという理由も載ってるね。
他の二つの理由と合わせて考えると、joinがstrのメソッドである事は
とても合理的だと思える。

目的のものが作れればいいんじゃない？

>>481
要素の型が str, unicode, bytes 以外のシーケンスに対する join は、使う場面が
少ないとはいえ一般化して考えれば存在しうるんだから、実際に出てきたときに
対応できないのはまずいね。

検索してみたら、trac の html まわりでちょうど >>469 の言っていたような事を
してる。
http://www.google.co.jp/codesearch/p?hl=ja#-EKtPk0GYAM/trac-0.10.3/trac/util/html.py&q=%22def%20join%22%20self&l=60

まぁ、一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
連結メソッドを使うという解になるし、文字列は非常によく使う型だから一貫性から
飛び出した特別扱いにするというのも間違いではない。
あとは、「それがしっくりくる(気がする)」だけで特別扱いを許す緩いRubyと、
「明確なメリット無しに一貫性は壊さない」Python の違いでしかない。

結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
程度の問題。

>>505
それだ!!

>>507
> 結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
> 程度の問題。

つまり結論は>>443ってことかよ。

> 一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
> 連結メソッドを使うという解になるし、
typo
一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
連結メソッドを入れるなという解になるし、

>>502
それはダウトだろう。
今のjoinは単に u'a' + '' + u'b' + '' + u'c' のようなものだろ。

>>> ''.join([u'a',u'b',u'c'])
u'abc'

「strのjoinだからstr」なんてことはない。
もしそうなら
''.join([1,2,3]) だって要素をすべてstr()にしてからjoinしてくれてもいいけど、ぜんぜんそうなってない。
どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

Pythonの仕様上、joinをstrのメソッドにする理由はわかるけど、それが自然かどうかというのはまた別の話。

>>502
>Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
>join_to_mystr なんてメソッドを Enumerable に追加するのか?

そうなったらjoinの引数として渡してやるだけでいいじゃん。
str.join(list) が list.join(str) となるだけ。

>>502
>一つの理由を見つけただけですべてを判った気になるな。
その理由すらみつけられなかったやつがえらそうに。
最初からFAQを紹介しとけばよかったものを、シッタカブリのせいでぐちゃぐちゃ。
こいつリアルでもおんなじことしてんだろうな。だれもおまえの言葉、ありがたがってないから。

日本人はすぐ個人攻撃に走る

論理的に反論できないんですねわかります

まぁ、論理的に反論できないやつが人格攻撃なんてよくあることだ罠

偉そうにはとても見えないけど、仮に偉そうだったとして、
実際この子よりは偉いだろうから仕方ないと思う。
相対的にこの子と対等かそれ以下になるのは、常人には逆に難しそう。

>>511
> どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

だから、どうしてstringのjoinしか見ないんだって何度もツッコミ入れられてるだろ。
joinがstringに定義されているから、引数はstringのiterableを取り、結果として連結されたstringを返す。
同様に、bytearrayのjoinは引数としてbytearrayのiterableを取り、結果として連結されたbytearrayを返す。
全部listのjoinが何とかするよりも、連結されるクラスが定義するpython式のほうがずっと自然だ。

>>512
> そうなったらjoinの引数として渡してやるだけでいいじゃん。
> str.join(list) が list.join(str) となるだけ。

そのlistはstrのこともbytearrayのことも何でも知ってなきゃならないわけだ。
ユーザ定義のクラスを連結したい時にはどうするの？

その場合はlist.join内部を+とかconcatとかで実装しておいて
その実装に使われたメソッドを各クラスで定義するのが自然ではなかろうか
一手間余計にかかるが

　　　　　　　_________
　　　　　／　　　　＼
　　　　／　　 ⌒　　⌒＼
　　／　　（ ⌒）　（⌒）＼
　　 i 　::::::⌒ （__人__） ⌒:: i 　　
　　　ヽ、　　　 `ー '　　／
　　　　/　　　　　┌─┐
　　　　i　　丶　ヽ{ .茶 }ヽ
　　　　ｒ　　ヽ、__)一(_丿
　　　　ヽ、___　　　ヽ　ヽ　
　　　　と_＿＿_＿ノ＿ノ

>>520
つまり連結演算子/連結関数を決め打ちするということね。
そんなことするぐらいならPythonのように連結されるクラスが提供するほうが
柔軟性があって、かつ、確実だと思うが。

>>520
> その場合はlist.join内部を+とかconcatとかで実装しておいて

それこそjoinのありがたみが台無しじゃん。
1つ1つ連結していたら計算量が大きくなるぞ。

＿＿
　　　￣￣￣二二ニ＝-
'''''"""￣￣
　　　　　　　　　　　-=ﾆﾆﾆﾆ=-

　　　　　　　　　　　　　　　　　　　　　　　　　／⌒ヽ　　　_,,-''"
　　　　　　　　　　　　　　　　　　　　　　 _　 ,（＾ω＾）　,-''";　　;,
　　　　　　　　　　　　　　　　　　　　　 /　,_O_,,-''"';　',　:'　;;　;,'
　　　　　　　　　　　　　　　　　　　　　(.ﾞｰ'''",　;,;　'　;　;;　　':　　,'
　　　　　　　　　　　　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　┼ヽ　 -|r‐､.　ﾚ　|
　　　　　　　　　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　　　　ｄ⌒)　./|　_ﾉ　 __ﾉ

Rubyの方が「(Matzの)気持ちよさ」のために汎用性や効率を
犠牲にしている所が多いので、RubyとPythonの仕様の違いで
「Pythonが間違っている！」と指摘するRuby厨はたいてい
視野が狭い。

>>525
おまえこそ視野を広く持てよ。

join()がArrayやListのメソッドである言語：
Ruby, JavaScript, Smalltalk(GNU), Perl(List用の関数に分類される)

join()が文字列のメソッドである言語：
Python, C#, PHP(文字列用の関数に分類される)

まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。
Pythonの場合はオブジェクト指向として考えたわけじゃなくて、シーケンスを引数にしたいという都合からそうなっているだけ。
joinを関数のようにとらえているとそれでもいいけど、オブジェクト指向的に考えると不自然ってだけ。
C#も、joinはインスタンスメソッドではなくスタティックメソッドだから、まさに関数的な考え方。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/366join/join.html

joinは、オブジェクト指向が強い言語では当然のようにArrayやListのメソッドだけど、関数が主体の言語では文字列のメソッドになることがある。
少なくとも、joinが文字列のメソッドである*べき*なんてのはただのねつ造だし、言語でいえば実は少数派。

まあいいじゃん、joinが文字列のメソッドでも。PHPと同じだと思えば。
525の視野が広くなることを願いながら、この話題はここで終了。

>>526が言語とライブラリの区別もつかない土方な件

> まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。

ぷ
オブジェクト指向的には"連結せよ"というメッセージは連結子になるオブジェクト(string)に送るのが自然だろ。
ArrayやListに送るという発想はSmalltalkの古いCollectionの設計に縛られているだけ。

>>526
オブジェクト指向的かどうかではなくて、型に対する態度の問題だと思うぞ。
型を強く意識する言語では、文字列以外も入るリストに要素を文字列として
連結するなんてメソッドを追加するのはあり得ない。

C#のstaticmethod の join は、 Python にも string モジュールに join
という関数がある。文字列に関連したメソッドなんだから str の
インスタンスメソッドにした方が便利だから、インスタンスメソッドに
なっただけ。

「オブジェクト指向的に自然」って、自分で思いこんでるのが
すべての人にとっても自然だと考えるのはなんでなんだろうね。

少なくとも文字列の連結処理を効率的に行うには文字列の
実装を知らないといけなくて、Arrayが文字列の内部実装を
直接弄って効率的な連結をするのは気持ち悪いな。

理想の世界で生きていきたくても、
蛇にそそのかされてリンゴを食べたからな。
現実と向き合わないとならないのだよ。

　　　　　　＿＿＿＿＿_.＿＿＿＿＿_.__
　　　　, '"――――‐, '"――――― ヽ`i1
　　　./ ∧＿∧　　 //'~￣￣|.|.|￣￣~|.||::||
　　 .i　（・∀・ .）　　i !　　_,.＿|.|.| 　. 　 |.l|::||
　[;].!_っ⌒'と　_0[;],l | 　f　_..┘|:.￣￣~ .|| ||.＿＿＿＿＿＿＿＿_,
　 ~l!=;:,...二二....,:;=iﾖ.'ｰ''"~ . __ !　　　 __.|| ||i リンゴジュース　￣i1
　　li..,._. ￣｡￣. _.,..!.|　　 ........~ﾉ..............~ || !|i,,＿__,,＿__,,＿__,,＿_,,!|
　　il＿｀}≡≡{´＿E|..::' /⌒ヽ'ヽ＿＿___/l|!=ｲ二/＿/ ⌒ヽヽ(ﾆ(]
.　 {=i:::::::[二]:::::::i=i::｣　 |i.（*）.i;;;;|i□□ー‐! ::::::::::|;;;;;;|ii.（*） i;;;|二l]
　　￣￣ゞ三ノ￣￣￣ゞ＿ノ￣　　ゞゞ三ノ　　￣ゞゞ＿ノ~　　　　≡3

>>511
>どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

要素のすべてが文字列である場合じゃないとjoinできないんだから
str/unicode/byteのメソッドなのでは？

>>513
俺は >>498 よりも先に >>494 を書いて、ちゃんと最後まで読んだ上で
RTFM と言ったんだが?

>>502
違う、全然違う。
str.join は、自動的に unicode へ格上げするような仕様になっている
だけで、実装は + (__add__) よりも効率的なものを使っている。
結果がたまたま等しいだけであって、sep.join([u'a', u'b']) と
u'a' + sep + u'b' は違う意味だ。

「strのjoinだからstr」というのは、逆に言えば「str以外のjoin」は違う動作を
するという意味でもある。

In [3]: k = bytearray('k')
In [4]: k.join([u'a', u'b'])
TypeError: can only join an iterable of bytes (item 0 has type 'unicode')

>>502 じゃなくて >>511 だった

reduce(lambda x,y: str(x) + ',' + str(y), [1,2,3])
これ reduce 使う前提でもっと効率良く書けますか？

>>> reduce(lambda x,y: x + ',' + str(y), [1,2,3], '')
',1,2,3'
>>> reduce(lambda x,y: x + ',' + y, [1,2,3], '')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <lambda>
TypeError: cannot concatenate 'str' and 'int' objects

ダメぽ orz

','.join(map(str,[1,2,3]))

>>539
＞reduce使う前提で

まあその前提条件はどうよという点はさておく

仮にreduceでどんだけがんばってもjoinよりは速くならないだろう

reduce(lambda x, y: '%s,%s' % (x, y), [1,2,3])
スマートさを求めるならこのあたりが限界かな

生成される一時オブジェクトの数のオーダが違うから無理だと思う

joinは？

joinを使うと一時オブジェクトなしで計算量O(N)。
reduceを使うと一時オブジェクトがO(N)必要で計算量O(N^2)。
どっちが良いかは明白だな。

Ruby の join って Enumerable のメソッドでは無くてリストのメソッドなんだな。
Pythonよりよっぽど気持ち悪い。

123

daa

なんかすげーあちこちに飛び火したな、joinネタ
ttp://d.hatena.ne.jp/methane/20090615/1245025996
ttp://blog.livedoor.jp/dankogai/archives/51226075.html
ttp://d.hatena.ne.jp/methane/20090621/1245532793

>>549
二行目
だんこがい
ってばかだな

class List(list):
def join(self, j = ''):
return j.join(map(lambda x: '%s' % x, self))

return j.join(map(repr, self))

>>550
>>> t = 'foo',
>>> t
('foo',)
>>> "%s" % t
'foo'
>>> str(t)
"('foo',)"
3行目のmethaneの方がスマート。
でも、 sep.join(x if isinstance(x, basestring) else str(x) for x in iterable) と
一行で書いた方が多分速いな。

>>551
repr と str は違う

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

test

pythonをはじめて使った時に ''.join()みたいな書き方は
あり得ないと思ったけど、慣れてしまえば使いやすいね。

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

JavaScriptもjoin使うの知って
まぁそうゆうもんかと思った。

キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。

アンチ少ないお

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

Black community in a town of 96% whites. ,

インデント記法は慣れれば気にならないし、
xx.lenghがなくてlen(xx)に統一されてるのも
個人的には嫌いだけど一理あるとは認めざる得ない。

でもスライスのx[n:m]の範囲指定は気持ち悪い。
なんか合理的な理由でもあるの？

他にどんな方法があるの？

>>562
日本語の勉強してから出直せ

>>563
[n:m] が n～(m-1) が気持ち悪いっていう意味だろうと E.S.P.

漏れは合理的だと思うけどね

>>565
ああそういう意味か
漏れも>>562が何言ってるのか判らんかった

例えばx文字目からy文字（文字数）取り出すとき
s[x:x+y-1]
とするよりも
s[x:x+y]
の方が計算が少なくて済むし

逆にpythonの中の人も
s[x:y]
が与えられたときに長さが
y-x+1
じゃなくて
y-x
となってここも計算が少なくて済む

小学生でも判るレベルの話

x文字目からy文字目まで取り出すとき
s[x:y+1]と計算が多くて済むから合理的

x文字目から最後の文字からn文字前まで取り出すとき
s[x:-n]と計算が少なくて済むから合理的

>>> 'abcde'[2:]
'cde'
>>> 'abcde'[2:-1]
'cd'
>>> 'abcde'[2:-2]
'c'

s = 'abcde'
s[2:len(s)]
s[2:len(s)-1]
s[2:len(s)-2]

Fortranに倣った

>571
a(:)みたいな配列を1-n, n-にわけたいとき、
Fortran a(:n), a(n+1:)
python a[:n] a[n:]
と、pythonの方がすっきりだ。これに気づいてからpythonのスライシングを許せるようになったw

0-origin の index の場合、 [begin, end) で範囲を表現するのが一般的
大きさ0の範囲を [x,x) で表現できる。

>>572
その表記ってC++勉強して初めて知ったけど一般的なん？

数学表記でしょ
閉区間とか開区間とか

ああそうか、思いっきり一般的だｗ
>>573で初めてとか言ったけど学校で習った覚えもあるわ

ヨーロッパとかだと半開区間を [a, b[ とか書いたりする

きもい

http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e
googleは新規のプロジェクトではpythonを使わないように勧めてるらしい

GAEもう使ってないから関係ないわw

だからといってRubyやPerlやPHPが代わりに使われることはないわけだが。

するとGuile？
名前も似てるしな
名前も似てるしな

Google のいちおしは Noop on Scala だろ

Javaってことじゃん
やっぱ時代はじゃばだよな！

Goって囲碁のプログラムかと思ったよ

シンプルで高速、Googleの新プログラミング言語「Go」
ttp://journal.mycom.co.jp/news/2009/11/11/025/?rt=na

Google の中の人、言語作るの好きだな

Noopが当て馬、Goが本命？

また中途半端なものを出してきたなw

単に Google の中の人は飽きっぽいだけだと思

test

なんでlist.rindexがないのか、理解できない

双方向リンクになってないから？
reverseかけてからやるしかないね

なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。

このスレが機能してないからでは

ここはスレタイがネガティブだから平和なのでは。
本スレに"人生の敗北者でも使える"を付けてみるとか。

そういえば昔は付いてたな

とあるエディットボックスの日本語入力中にIMEの変換中の文字列を取得したいのですが
from ctypes import *
from ctypes.wintypes import *
ImmGetContext = windll.imm32.ImmGetContext
ImmGetContext.argtypes = [c_int]
ImmGetContext.restypes = c_int
ImmGetCompositionString = windll.imm32.ImmGetCompositionStringA
ImmGetCompositionString.argtypes = [c_int, c_int, c_char_p, c_int]
ImmGetCompositionString.restypes = c_int
GCS_COMPSTR = 0x0008
hwnd = エディットボックスのウインドウハンドル
himc = ImmGetContext(hwnd) # 入力コンテキスト取得
buf = create_string_buffer('dummy', 1024) # バッファ作成
print ImmGetCompositionString(himc, GCS_COMPSTR, buf, 0) # IME変換中の文字列の長さに応じた値が返ってくる
print ' '.join(('%02x' % ord(c)) for c in buf.raw) # 常にバッファ作成時の初期化文字列「'dummy'」しか返ってこない
…となってしまいます
ctypes のポインタ渡しの説明を見ると c_char_p ではなく
create_string_buffer で作ったものを渡せとあるので
そうしたつもりなのですが期待通りに動きません
どなたか上手く取得する方法を教えてください
ちなみに
buf = create_string_buffer('dummy', 1024)
print '>',
# libc.scanf('%s', buf)
cdll.msvcrt.scanf('%s', buf)
print ' '.join(('%02x' % ord(c)) for c in buf.raw)
print buf.value
こちらは動きます
バッファオーバーランとかの突っ込みはなしでおながいします

ImmGetCompositionString(himc, GCS_COMPSTR, byref(buf), 0) は？

ImmGetCompositionStringの第4引数を0 => len(buf)あるいは1024

ImmGetCompositionStringの
3つ目の引数はLPVOIDだけど
char*として扱っていいのか？

>>596-598
ありがとうございます

ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf.raw))

で取得出来ました

なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。

>>597
print ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf))
print ' '.join(('%02x' % ord(c)) for c in buf)
print buf.value

で大丈夫でした

あと
変換中の文字列が len(buf) の長さよりも長いとき
ImmGetCompositionString の戻り値は 0 になるみたいです

ありがとうございました

>>600
本スレだったら
len(buf)ってなにそれ？普通はbuf.len()だろww
ってなってるな。

>>602
こっちくんな

　　　　ﾍ⌒ヽﾌ
　　　（　・ω・）　㌧㌧
　　　/ ~つと）

C++アプリにPythonを組み込んでみたいんだけど、
BlenderってアプリはPCにPythonをインストールしてないとPython動かせないじゃないですか。
アプリからPythonスクリプトを実行するにはPython環境を必要とするものなんですか？

あとマルチコアCPUだと実行が遅くなるって本当ですか？

Ruby使うと良いよ

>>606
ありがとうございます
Rubyの方が組み込み言語として枯れてるんですか？
PythonやJavaScriptに比べるとユーザ少そうだし一番トラブりそうと思い込んでました

cython

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

保守age

ﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞ ―Pythonによるﾊﾞｲﾅﾘ解析技法が欲しい

LLでバイナリってのも今ひとつ何をねらってるのかよくわからんな

C言語でsegvしながらガリガリ切り貼りするよりだいぶ楽なことが多いと思う

>>612
解析なら別にいいんじゃね？

ここだけまったりした雰囲気だな。

∧＿∧
( ´･ω･) みなさん、お茶が入りましたよ・・・・。
( つ旦O
と＿)＿) 旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦

本スレ荒れてるなぁ...

本スレが荒れてるんじゃない
君の心が荒れているんだ！

　　 ┌─┐
　　 │●│
　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘

何でNoneオブジェクトまでINCREF,DECREFしてるん？

よくわかんないけど、毎回Noneかどうか比較するよりもINCREF, DECREFしてGCの対象から外した方が軽かったんじゃない？

pyscripterのバージョンがいつの間にか上がってる
開発に波あるみたい

from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
httpd = HTTPServer(('', 8080), SimpleHTTPRequestHandler)
httpd.serve_forever()

http://twitter.com/yukihiro_matz/statuses/29317109670

yukihiro_matz: 英語圏でRubyとPythonを比較する記事を見ることが少なくなってきた
のは、RubyとPythonでクラスタが分離してきたからか。逆に日本語でRubyとPythonを
比較する記事を見かけるのは国内でのPythonの地位が向上したからか。

　　　　　　　　　　　　　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　／⌒　　⌒＼　　 |　　 |
　　　／（ ●）　（●）＼　 !　　 !
　／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　　　 | 　／　＜こいつ最高にアホだお
　＼　　　｀ー'´ 　　／／
　　/　＿＿　　　　　　　/
　　(＿＿＿）　　　　　　/

　　　　　　　　　　　　　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　／⌒　　⌒＼　　 |　　 |
　　　／（ ●）　（●）＼　 !　　 !
　／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　　　 | 　／　＜こいつ最高にアホだお
　＼　　　｀ー'´ 　　／／
　　/　＿＿　　　　　　　/
　　(＿＿＿）　　　　　　/

まつもと君。まだそんなこと言ってるのか・・・・

アップルに捨てられたからでしょうに・・・

AppleはMacRuby開発してんじゃん

age

Python って、インデントでブロックを表現する変態言語だけど、
実は Ruby 並には機能が詰まった言語らしいくらいのイメージしかないんだけど。
正直触ったことがほぼないからよくわからん。

そもそも、あまり書籍を見かけないし、web のフレームワークの話もみかけない。
Google にはよくしてもらっている程度しか優位性をしらないんだけど。

>>629
まあ、まずはざっとこれ読んでくれ。
http://stackoverflow.com/questions/1113611/what-does-ruby-have-that-python-doesnt-and-vice-versa

>>630
ざっとみたが、英語は不得意なので『インデントでブロックを表現する変態言語』くらいしか伝わらなかった。

どうせコード書くときにはpythonに限らず適宜インデントすんだろ。
むしろ余計な{}なんかがないだけよっぽど読みやすい。

大学のときまったくインデントを使わずにJavaを書く教授がいた

>>632
はげ

おまいらスレ違い

あっちいけ
http://hibari.2ch.net/test/read.cgi/tech/1169473442/

test

てすてす

改行

テスト

quit()

test

hogehuga

test

あり～ん

test

ウンチ

お！これは。
てすと

ここのtestってpythonのスクリプトで書き込みのテストをしていると考えていいでしょうか？

Python 3.2.1 のリリースがまた延期されちゃったね。

○ンチ専用

6月19日にFinal出るのかね？本当に。

Yes, I do.

出るかな出るかな～？

いよいよ今日だね。

出たのかな？

勉強スレの方にアンチが沸いてるのに、こっちはまったり。

超初心者スレが無くなっちゃったから行き場がないのでは？

出ませんでしたよ。

When will Django run on Python 3.x

まだ枯れていない発展途上の言語だから仕方ないけど、
バージョンの乱立はどうにかならないもんかな。

あれ？もう4.xでも出たの？

Perl の 6 はいつになるのよ。

菅の辞任よりも早いかも知れないな

今年だけでも 2.5.6, 2.6.7, 2.7.2, 3.0.1, 3.1.4, 3.2 出てる
小数点第一位が違うと別バージョンなんじゃないの？
それとも、2系と 3系の 2つだけという解釈なのかしら

2.xでは、2.7系以外は互換性の都合上古いの使ってる人のためのバグフィックスじゃないの？
3.xは絶賛開発中。

世の中にはバージョンが 0.1 上がっただけで
文法の下位互換性がなくなる言語があるんよ

GAEが2.7じゃないのが

古くなったものをすぐに切り捨ててしまうと
「こんなサイクルの短かい言語を使えるかいな」
となってしまうから、メンテナンスは必要だよね。

バージョンアップのたびに大きく仕様が変わるが、滅多に上がらないから問題ない
有名な言語があります。

C++ かな?

そういった意味では面倒見がいいのかなあ

COBOL超安定。2002で大冒険だけど。

2系は 2系として残り続けていくわけだね

いつかまとまるさ

.

いまいち使い道がわからない

test

いめぇじきゃらが蛇なんてイケてない

いつまで移行に時間かけてるんだろうね

おいC99の悪口はやめろ

おいRubyの悪口はやめろ

ふむ

ふも？

ふもふも

ふーもー

fumo

fumo-fumo-land

oha-

>>681

ゴミはゴミ

>>688
ふも？

天使さん戻っておいでよ

Ruby 1.8.7-p352 をビルドした人いますか？

>>691
Rubyスレで聞いたほうが…

スレが乱立しすぎてると思うんだよね
Pythonは本家スレ一本でいくべき

Rubyバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね

いちいちSHIFT＋４キーおして＄打ちまくってる感触はどう？

土方が何をいっても

Python は日本でもかなり人気が出てきたね
日本語訳の本がたくさん出てきたからかな

list
[1, 2, 3, 4, 5, 6, 7, 8, 9]
['apple', 'google', 'micro']

tuple
('a', 'b', 'c', 'd', 'e')

set
{1, 2, 3, 4, 5, 6, 7, 8, 9}

dict
{'2ch': 'good', 'twitter': 'bad', 'facebook': '?'}

∨∨∨∨
(((((((( Rubyバカにしてる子ってさ ))))))))（嘲ッッッッ笑
∧∧∧(爆ッッッ笑！
∨
(((((( 変数に＄ついてる言語触ってるって事だよね ))))))（爆ッッ笑ッ!!
∧∧∧∧∧∧(爆笑ッッ
∨∨∨
(((((((( いちいちSHIFT＋４キーおして＄打ちまくってる感触はどう？ ))))))))（嘲笑ッッｗ！！嘲笑！
∧∧∧(ｗｗッ
∨∨∨∨∨
(((((( 土方が何をいっても ))))))(爆ッッッ笑ッ！！ｗｗ！！
∧∧∧∧(爆!!爆ッ!!

天使#test_s

「天使の煽り」の提供でお送りしました

ひじかたと読む

3.2.1はまた出ないのかしら。
工程管理どうなってるの？

出てるよ。
Pythonの評判を落すような発言は慎しみたまえ。

てｓｔ

test

ninja

test age

0x00c4

u00c4

Ä

Cythonでインスタンスを複製する方法ってないですか？
copy.copyやcopy.deepcopyだと、self.aやself.Aの値がコピーされず、空になるのですが
通常のPythonのままならうまくいきます

#abc.pyx
cdef class abc:
　cdef:
　　public int a
　　public list A

　def __init__(self,a):
　　self.a = a
　　self.A = [a]

　def Add(self,b):
　　self.A.append(b)

from abc import *
i=abc(1)
i.A　# [1]
j = copy.deepcopy(i)
j.A　#
i.Add(2)
i.A　# [1,2]
j.A　#
j.Add(3)#AttributeError 'NoneType' object has on attribute 'append'

あれ？レスする場所が間違えてた…
Pythonのお勉強にレスするつもりが、すいません

まぎらわしいこんなスレはさっさと消化するに限る

Python ready

Go

>>> exit()

indent

ninja!

ninja

nin-nin

huga-

test

ume

test

にん

ビルドできん

.

test

てす

下げ進行で

連続投稿が出来無いだと...

でけた

てす

さげ

先は長いのう

ぴちょん

おは

こん

番地は

右向いて

Linux村から

おは

乙女の”お”

おは

おやすみ

おは

ヨーグルト

おは

大好きだよ

Python 3.2.1

3.2.2 が来てた。

新バージョンが出ても話題にならないのは何故だ？

坊やだからさ

ほしゅ

なぜ Python ユーザーは少ないの？
ttp://python.matrix.jp/columns/column2/

馬鹿には無理

プログラミング言語界のツチノコだと思って許してくれ頼む

2と3の互換性がなくて糞

>>761
それはrubyも同じだしなぁ・・・
それより、pythonのオブジェクト指向がC++/Java/C#/Rubyより独特すぎて戸惑う

>>> class Foo:
pass

メソッドもフィールドも無いクラスを定義

フィールドやメソッドを使おうとすると、もちろんエラー

foo = Foo()
foo.a これはエラー

ところが、

foo.a = 10

とかすると、

何もフィールドが無かったクラスにフィールドが生まれる（pythonではフィールドのことをアトリビュートと呼ぶらしいけど）

動的言語らしいと言えばそうだけど・・・実績こそ世界的には多いけど、保守とか考えた設計じゃないよなぁ・・・

>>762
それはrubyも同じだしなぁ・・・

javascriptもやで～

説明しよう、つまり、お風呂にヘビがいて（本当はモンティだけど）、穴に入ってしまた、ちょうど時を同じくRubyの指輪が排水口に、仕方ないので、ジャバ。

こう言っ具合の、開発者が、アンチに書きこむのである。

つーか、Rubyのアンチスレに比べて全然書き込まれないな
不便とか、不満とか、無いのん？

はい

日本人を叩きたがる日本人は多い

pythonはなぜかアンチスレの方が親切な人が多い

ツンデレ

あげ

馬鹿には無理

グイド大激怒！こんな糞コミッタ－しか育たないんならPython開発なんて意味ないね
http://ikura.2ch.net/test/read.cgi/bread/1325584365/

>>773
ゲイドはそんなことを言わない。

Linusなら言うかもな

>>775
言ってるよ、むしろこっちが早い

[ Linux ] 【Linux】カーネル総合6【Kernel】
543 名前：login:Penguin [sage]： 2012/03/25(日) 00:29:35.22 ID:QmHRZWVc
リーナス大激怒！こんな糞コミッタ－しか育たないんならカーネル開発なんて意味ないね
http://ikura.2ch.net/test/read.cgi/bread/1325584365/

>>776
リーナスも言わない。
ストールマンなら言いそう。

>>762
いまさらだが __slots__

ttp://linux.slashdot.jp/story/12/03/01/0913255/Linus-Torvalds%E6%B0%8F%E3%80%81openSUSE%E3%81%AE%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E4%BB%95%E6%A7%98%E3%81%AB%E6%86%A4%E3%82%8B
> ワイヤレスネットワークへのアクセスや、用紙のプリントアウト、日付時刻設定の変更を
> 行うのにもルートパスワードが必要だと考えているなら、お願いだから今すぐ死んで頂きたい。

ttp://www.atmarkit.co.jp/fsecurity/special/103kernelwatch/kernelwatch01.html
> セキュリティをやってるやつらは狂っている。

リーナスなら言ってもおかしくない。

Linuxのアクセス権限管理が単純すぎるのがダメなんだがや。

Unixの基本設計がそうなんだから諦めろ、って面もあるな

｢人魚さんにもパイソンはある！｣

スレッド乱立荒らし出没中につき
dat落ちしないように保守

スレチですまんがpython愛してる

age

だす

Python 2.7.3, last updated Apr 10, 2012
インストールしました(^o^)/

C:\work>python -V
Python 2.7.3

「言葉（服装風紀世相秩序）の乱れ」はそう感じる人自身の心の乱れの自己投影。他力本願で問題解決力が低く対外評価を気にする不寛容者ほど、自己防衛の為にマナー規律モラル礼儀作法ルール法律を必要とする。嫌悪憤怒激昂は無知無明無能の自己証明／感情自己責任論

○ちんこ
http://toro.2ch.net/test/read.cgi/tech/1249737531/

みなさんお世話になりました
明日で2ch終了らしいので
今のうちに最後のご挨拶をしておきます

ぬるぽ

len(list)とか書くの面倒だからlist.len()とさせろ
ついでに引数の括弧も無くしてlist.lenと書かせろ
hoge.to_sとかhoge.to_aとかhoge.to_iとかやらせろ

むしろrubyで先頭に「#なんちゃら」とか宣言すればインデントをブロックとして扱ってくれるようにすればいいんじゃ
唯一Pythonが勝ってるところだし
○○ do
　～
end
を
○○:
　～
にするだけなんて簡単でしょ

○○ do |key, value|
　～
end
は
○○: |key, value|
　～
でいいし

pythonの関数とメソッド入り混じってるのは本当に気持ち悪い
メソッドで統一しろと

Rubyになれると他の言語の括弧の入れ子が書きづらい上に見づらくてしゃーない

>>794
http://python.rdy.jp/wiki.cgi?page=FAQ#p10

>>796
関数で統一されてるのがPythonでしょ

何故メソッドを廃して読みづらく書きづらい関数を用意するのか
謎である

元々、Pythonは手続き型スクリプト言語として設計されて誕生したからね
そして、後からオブジェクト指向や関数型の特性を「接ぎ木」した

この「接ぎ木」は別段に変な事でも何でもなくて、
手続き型言語Cにオブジェクト指向を「接ぎ木」したC++が代表例だし、
最近はJavaに関数型のラムダ式が「接ぎ木」されようとしている
またC++やJavaでは、後から総称型が「接ぎ木」されてきた

Pythonは、これからも進化し続けるであろう
標準ライブラリの後方互換性を捨て去り、
たとえ(過去にもあった)Python 3.x から 4.x への世代間断絶があろうとも、
世界中のプログラマは新バージョンへと華麗に移行していく
（技術レベルの低い、日本のPythonプログラマは置いてきぼりかな....）

> Pythonは手続き型スクリプト言語として設計されて誕生したからね
よくRubyユーザーはこういうんだけど、
そんな事実はどこにもないから。

> たとえ(過去にもあった)Python 3.x から 4.x への世代間断絶があろうとも、
いや、断絶してないから。
sixみたいに違いを吸収するライブラリまであるし。
数年置きに互換性がなくなる某スクリプト言語と違って
Pythonが後方互換を切ったのは20年で1回だけだ。
つーか、Cですら初期のK&Rの頃とは文法が違う。

20年も開発してたか？

>>802
>> たとえ(過去にもあった)Python 3.x から 4.x への世代間断絶があろうとも、
>いや、断絶してないから。

これは、Python 2.x と同 3.x の世代間に存在する、
標準ライブラリ互換性の断絶ではないのかな？

> 43 名前: デフォルトの名無しさん Mail: 投稿日: 2014/01/08(水) 17:35:05.69
> ちなみに、python2と3でmap関数の返り値違う
> python2はリスト型
> >>> type(map(add, a))
> <type 'list'>
> python3はmap型
> >>> type(map(add, a))
> <class 'map'>

>>802
もう一つの(過去にあった)標準ライブラリ互換性断絶の例

> 940 名前: デフォルトの名無しさん Mail: sage 投稿日: 2013/12/31(火) 03:44:40.65
> >>939 エラーにならなくなった理由は別にある。
>
> 2.x
> range -> リストを作る。OverflowErrorでなくとも、大きなメモリを確保しようとして
> MemoryErrorになることもなる。
> xrange -> range型のオブジェクトを返す。
> rangeオブジェクトの各属性は構造体で (Cの)long型で宣言されてるので、値が範囲外だと
> OverflowError
>
> 3.x
> range -> range型のオブジェクトを返す。rangeオブジェトの各属性の型はPyObject。
> pythonの数値(多倍長整数）を持つようになったので、2.xの時の制限はなくなった。

>>802
>よくRubyユーザーはこういうんだけど、

Rubyの話題はスレ違い

Rubyの話がしたいなら「Rubyについて（アンチ専用）」へ
Python vs. Ruby が希望であれば、バトロワスレへ

Python関連スレをちょっとでも覗けば、
序盤から終盤まで 2.x or 3.x の話題だらけじゃん。
これでもPyhtonの後方互換性に問題無しと言えるなんて、
頭がおかしいんじゃないのかなあ....。

なぜ多くのプロジェクトがPythonの古いバージョンをサポートし続けるのか
ストーリー by headless 2014年01月12日 12時55分
http://developers.slashdot.jp/story/14/01/11/2115245/

ペコ「ロバｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

>>795
おれインデント自信が無いよ。
そんな1段なら、わかるけど、実際は、もっともっとふかいのだ。
んなもんわかるわけないよ。みんなどうやってるんだろう？

Python用にかきかえなければならないとおもうと…いやんなるよ
将来のためにそうするべきか。Pythonをあきらめるべきか

>>810
書く時は、エディタのアシスト任せ。後でツールで一括して自動整形。

>>810
インデントの深さを表示できるエディタを使うとか
いくらでもやりようはあるでしょ

python初心者だけど面白いよ面白い！でもpythonerが排他的っぽい；；

代入演算子が値ではなくてリファレンスの代入という仕様はハマるな。
みんな慣れてるの？
他の言語と基本的なことが違い過ぎる。

それ Python に限った話じゃないよ

Pythonは他の言語からの人がはまる仕様が結構ある。
デフォルト引数が評価されるタイミングとか。

FAQに纏まってるので、早めに目を通すといいよ

オブジェクトを指す変数がリファレンスだなんて、ほとんどの言語であたりまえだわ。
むしろポインタを生で扱わないといけないので、明示的にデリファレンスをしないと
いけない、CとC++のほうが例外的。

PHPは、何も考えてない言語仕様だから変なことになってるけど、まぁPHPだからw

>代入演算子が値ではなくてリファレンスの代入という仕様はハマるな。

これは、割とどの言語でも繰り返されてきた話題なんだけど、
言語間での"リファレンス/参照"という語句の、食い違いによる説明の混乱というものがあって

C++で言う(alias的な機能の)"リファレンス/参照"は、Pythonにはなく、
C/C++の語句で言うなら、Pythonでのオブジェクトのリファレンスとは、
単に"オブジェクトの構造体を指すポインタの値"。

Aという言語を使ってきた人がBという言語を使い始めた時にハマるポイント、
なんてのは、どんな組み合わせでもまず間違いなく絶対あるよな。

インデントの使用で読みやすいとは言うが、糖衣構文やデコレータバンバンだから
実際の現場で使われているアプリのレベルのソースはちょっと分かりにくい

よくある話だが、教育用と実用性を両立させようとするとどうしてもこうなる

教育用として設計されてはいねーし。デマ。

デコレータで読みにくくなるなんて
そりゃ知能が絶望的に足りてないんだよ

デコレータ使わず、糖衣構文を展開した形で書かれていれば理解できるんだい、
（と信じようとしている）。

時間周りがめんどくさい

日本ではPythonはもう終わりだ...
発展はない
始めるのはゆとりばかり
質問なんかも酷いもんだ
PHPより遥かに劣る

osとshutilに分かれてる意味がわからない。
日付が使いにくい。
lenがオブジェクトのメンバに無いのがおかしい。
absがmathじゃないのはおかしい。

はじめたばかりだけど、ざっと見てなんかライブラリがとっ散らかってる印象。

気になるのは最初だけだから
通過してしまえば一瞬で忘れられる
そんな小さいことにいつまでも構ってられるほど python の世界は狭くはない
安心して使い続けるがよい

ライブラリがとっ散らかってると、マニュアル引くとき困るんだが。
このくそライブラリのせいで学習曲線絶対急になってるよね。イラつくわ。

sysとosとか、きちんと意味があって分けられているけどな。

なんでもグローバル名前空間にぶち込んであるのが好きならPHP使ってろよw

また始まった

> lenがオブジェクトのメンバに無いのがおかしい。
__len__メソッドが代わりにあるから使えよ。
ちなみにlen関数がやってくれてる型チェックも自前でやれよ。

型チェック？なぜそんなことをしなければいけないのか

流石 __len__ すら知らずにアンチを気取るマヌケは言うことが違うなw

なんかガキの罵倒スレになってきたな。

外部関数とメンバ関数を一々覚えんのがめんどいよな

Pythonってリスト内包表記が中途半端で使いにくい。

array = [1, 2, 3, 4, 5]
[x*2 for x in array if x<3]
これはmap とfilterの組み合わせで、プログラミング言語として考えたらこんな複雑な構文は面倒くさいだけだし、
x*2 for x の部分をlambdaだと考えたら仮引数が後ろに来ていて非常に読みにくい。

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
[[c*2 for c in r] for r in matrix]
数式に近い書き方なんだと考えたら考えたで、行列のような多次元データ構造を扱うには
内包表記をネストしないといけなくなって複雑になる。結局何をやるにしてもnumpy頼みになる。

Pythonの内包表記が中途半端ってどういうこと？
Haskellの内包表記も似たようなもんだよ
それに慣れると（Haskellにおいてすら）mapやfilterより読みやすい

[x * 2 | x <- array, x < 3]
map (* 2) $ filter (< 3) $ array

>x*2 for x の部分をlambdaだと考えたら仮引数が後ろに来ていて非常に読みにくい。

そんな香具師いるんかね
むしろ
[2*x for x in array if x<3]
とかのとき
[('%s'*x) for x in array if x<3]
と解釈されるはずだと思うところが
ひょっとすると
['%s'%(x for x in array if x<3)]
の可能性も捨てきれないと思ってしまう

なんか切り貼りしてたらおかしくなったので訂正

むしろ
['%s'%x for x in array if x<3]
とかのとき
[('%s'%x) for x in array if x<3]
と解釈されるはずだと思うところが
ひょっとすると
['%s'%(x for x in array if x<3)]
の可能性も捨てきれないと思ってしまう

>>838
数式に親しくないプログラマにとっては「今のところ」後者のmapとfilterで平凡に書く方が分かりやすいと思うけどな。
Haskellでは後者の書き方でも色々と非凡になるけどｗ
（今のところってのは、昔はそもそも無名関数自体一般的じゃなくてループの方が分かりやすい時代だった。
今は無名関数くらい誰でも使う。何が分かりやすいかも時代で変わってくるから、時代に合わせたプログラミング大事）

本題。中途半端って言ったのは、そこじゃなくて。
今、内包表記を苦もなくスラスラ読めるプログラマってどんな奴だ？
→数式を読めるプログラマだろ
→数式を読めるプログラマはどんなプログラムを書く？
→数学の問題を解くプログラムだろ
→数学の問題をプログラミングするなら、行列の各要素を二倍するなんてこう書きたいだろ（Rのように）
matrix*2

>数式に親しくないプログラマ

そんな香具師いるんかね

>>841

>→数学の問題をプログラミングするなら、行列の各要素を二倍するなんてこう書きたいだろ（Rのように）
>matrix*2

それこそ numpy でいいやん

多分日本語的に読みづらいんだと思うよ。結果が先に来るから。

日本で産まれた(ω) Ruby にも後置 if とかあるのに

Ruby は大概書きたい方法があるじゃん

いくらPythonにへびネタが多いとはいえこういう表紙は駄目だろう
冗談抜きで表紙が気持ち悪くて手に取れないレベル
これが原因でPythonあるいは授業に悪い印象しか残らなかったら学生が可哀想
http://www.skylit.com/mathandpython.html
https://www.packtpub.com/big-data-and-business-intelligence/learning-python-data-analysis

カバー付ければ良いだけじゃん
全編写真集なら嫌だけど

ジャポニカ学習帳みたいに表紙は植物だけにすればいい
O'Reillyも

ああ
アンチすれだったか
いつも調子で書き込んでたゎ
http://ecx.images-amazon.com/images/I/518wm5u3TjL.jpg
http://www.chrischeng.com/wp-content/uploads/2012/11/Python-271x300.jpg

アンチじゃないが表紙ひどいwww

本当だ、何でこんなリアル志向

>>847
俺は別に平気だけど、もはや何の本か分からんなw

>>842
いまどき香具士って・・・