【実験台】 Python 3.0 のお勉強 Part 1 【非互換】

**デフォルトの名無しさん** · 2009/02/19(木) 22:30:15

Python 3.0 は隔離スレを作るべきだと思うのは俺だけかな？
そもそもあれは実用で使うには時期が早すぎるわけで、ここで
普通に語られても困る。
--------
別に
--------
細分化する必要性が全く感じられない。
各自がレスの内容を収拾選択すればいいだけ。

**デフォルトの名無しさん** · 2010/06/22(火) 00:39:20

pythonから発展した話題だし、少しくらいいいんじゃね？
ところで、お前らpythonなにに使ってる？

**デフォルトの名無しさん** · 2010/06/22(火) 01:30:20

>>233
電卓代わり、CGI、C/C++で書くほどじゃないプログラム全般。
まともに使い方知ってる言語がC/C++とPythonしかないから、ある意味で楽。

**デフォルトの名無しさん** · 2010/06/22(火) 02:25:43

>>233
spamメールのフィルタ

**デフォルトの名無しさん** · 2010/06/22(火) 02:34:24

>>233
領土問題と同じで、少しくらいと譲歩してたら乗っ取られる。

**デフォルトの名無しさん** · 2010/06/24(木) 21:36:26

領民あっての領土だから大丈夫

**デフォルトの名無しさん** · 2010/06/26(土) 08:50:39

pythonだと作るのが非常に楽なので、python常用して
python2だと日本語が扱いづらいので、python3導入して
研究で最適化アルゴリズムとか強化学習のプログラム作ったけど
先輩のc言語で書かれた同じ最適化アルゴリズムで作った巡回セールスマン問題と
実行速度比較したら、10倍以上差があるんだが・・・先輩のが数分で、自分のが数時間
読みやすさ重視でプログラム書いたからループ内で不要な処理とかかなりしてる気もする
python3のコンパイラないかな

**デフォルトの名無しさん** · 2010/06/26(土) 08:57:15

python3にしか対応してない素晴らしいモジュールを作れば移行が早くなるかも!!

**デフォルトの名無しさん** · 2010/06/26(土) 11:11:07

>>238
あったとしても、多少マシになるくらいでCにはとてもかなわないと思うよ。
psycoって3.x対応してないよなぁ。

**デフォルトの名無しさん** · 2010/06/26(土) 11:29:12

10倍ですむならマシだな
ものによっては100倍ぐらい差がつく

**デフォルトの名無しさん** · 2010/06/26(土) 11:29:38

>>240
多少でもマシにしたいほど時間がかかる・・・
たしか対応してない

**デフォルトの名無しさん** · 2010/06/26(土) 11:30:34

先輩が数十分、自分のだと1日とかそんな感じ

**デフォルトの名無しさん** · 2010/06/26(土) 11:51:10

Python2 にもどして、 PyPy 使うと良いよ。
今日 PyPy-1.3 がリリースされたし。

**デフォルトの名無しさん** · 2010/06/26(土) 20:35:28

python3ってctypes使えますか？

**デフォルトの名無しさん** · 2010/06/26(土) 21:16:25

使える

**デフォルトの名無しさん** · 2010/06/26(土) 23:37:58

ctypesいじくり中。
pointerとbyrefってどう使い分けるんだ？
あとlistをそのまま配列としてcに渡したり出来ないのね。
内包表記でばーんと渡したりって訳にはいかないね。

**デフォルトの名無しさん** · 2010/06/26(土) 23:45:14

とりあえず全部PythonでつくってProfilerかけて時間のかかる処理だけSWIG+Cで書いてるけど
このオーソドックスな方法は素晴らしいっすよ

**デフォルトの名無しさん** · 2010/06/27(日) 02:10:57

Cythonも素晴らしいよ。
ちゃんとPython3にも対応してるし。

**デフォルトの名無しさん** · 2010/06/27(日) 15:23:06

#! /usr/bin/env python
# -*- coding: utf-8 -*-
import datetime

def sample_loop(n):
L = []
for i in range(n):
L.append(i)
return L

def sample_comprehension(n):
return [i for i in range(n)]

d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

sample_comprehension(50000000)
d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

sample_loop(50000000)
d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

実行結果
2010-06-27 15:19:23
2010-06-27 15:19:46
2010-06-27 15:19:46

Python3だとリスト内包表現って遅いの？

**デフォルトの名無しさん** · 2010/06/27(日) 15:43:03

>>250
2.6でも3でもリスト内包の方が速い。
2.5以前は知らんが、たぶんリスト内包の方が速い。
http://dsas.blog.klab.org/archives/51742727.html

**デフォルトの名無しさん** · 2010/06/27(日) 15:50:16

こうしないと同じ条件にならないんじゃ？

def sample_comprehension(n):
L = []
return [L.append(i) for i in range(n)]

**デフォルトの名無しさん** · 2010/06/27(日) 20:15:46

CPythonって、リストの実装って配列だっけ？双方向リストだっけ？

>>250
sample_comprehensionとsample_loopの順番を入れ替えてみても結果変わらない？

32bit環境だと50000000要素だと、配列なら約200MB、双方向リストなら約600MBのメモリ確保が必要になって、
それに時間がかかったんじゃないかなぁ。
一旦確保したら、ひとつめのsample_comprehensionで作ったリストはGCの対象になるから、新たにメモリ確保の必要がない。
だから2つめのsample_loopは早かった、と予想してみる。

**デフォルトの名無しさん** · 2010/06/27(日) 20:45:54

>>252
適当なサイトのソースをコピペして実行しただけだから深く考えてなかった
それでやってみる
>>253
順番入れ替えても変わらなかった

**デフォルトの名無しさん** · 2010/06/27(日) 20:48:28

>>251
そうそうこのページのソースをコピペして実行した
人が居たから、かなり適当に書いた
だからtimeじゃなくdatetime使ってたり

**デフォルトの名無しさん** · 2010/06/27(日) 21:03:11

#! /usr/bin/env python
# -*- coding: utf-8 -*-
import datetime

def sample_loop(n):
L = []
for i in range(n):
L.append(i)
return L
def sample_comprehension(n):
L = []
return [L.append(i) for i in range(n)]

d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

sample_comprehension(50000000)
d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

sample_loop(50000000)
d = datetime.datetime.today()
print (":",d.strftime("%Y-%m-%d %H:%M:%S") )

結果
2010-06-27 21:01:04
2010-06-27 21:02:11
2010-06-27 21:02:12

**デフォルトの名無しさん** · 2010/06/27(日) 21:30:30

>>252
正直その糞コードで何をしたいのか全然わかんねえ
list.append()はNoneを返すから
それって結果は
[ None ] * n
になるよな

**デフォルトの名無しさん** · 2010/06/27(日) 21:53:13

#! /usr/bin/env python
# -*- coding: utf-8 -*-
import datetime

n = 50000000

d = datetime.datetime.today()
print ("for文リスト作成開始:",d.minute,"分",d.second,".",d.microsecond,"秒")
L = []
for i in range(n):
L.append(i)

d = datetime.datetime.today()
print ("リスト内包　　　　 :",d.minute,"分",d.second,".",d.microsecond,"秒")
L = []
L = [i for i in range(n)]

d = datetime.datetime.today()
print ("終了　　　　　　　 :",d.minute,"分",d.second,".",d.microsecond,"秒")

for文リスト作成開始: 51 分 11 . 930000 秒
リスト内包　　　　 : 51 分 53 . 554000 秒
終了　　　　　　　 : 52 分 9 . 919000 秒

**デフォルトの名無しさん** · 2010/06/27(日) 23:05:53

糞コード貼り禁止

**デフォルトの名無しさん** · 2010/06/28(月) 03:36:29

>>256
ほんとだ。すげー、ループはえー、と思ったらインデントを
def sample_loop(n):
    L = []
    for i in range(n):
        L.append(i)
        return L
にしてた(・ω・`)
2.5で動かしたからrange()がイテレータじゃなくてリスト返すおかげで数字的にリアルだった。

にしても、今時のCPU速いな。Pen4だとC++で同じような処理書いても2秒かかったぞ。
#include <vector>
#include <iostream>
class Range{
private:
int end;
int now;
public:
Range(int n) : end(n), now(0){}
int next(){return now == end ? -1 : now++;}
};
int main(){
Range range(50000000);
std::vector<int> l;
int i;

while((i = range.next()) != -1) l.push_back(i);
return 0;
}

**デフォルトの名無しさん** · 2010/06/28(月) 03:39:39

>>252
L.append自体をすることが目的ならそうだけど、
L.appendの副作用でリスト作るか内包表記でループ作るかどっちが速いかを調べたいなら元々のであってる

**デフォルトの名無しさん** · 2010/07/01(木) 06:54:38

Cyhonの使い方を勉強しよう
まだほとんど調べてないが、使い方がよくわからない
てかトイレ行きたくて集中出来ない

**デフォルトの名無しさん** · 2010/07/01(木) 12:02:02

先に下痢を治せ

**デフォルトの名無しさん** · 2010/07/07(水) 10:50:19

結局ある程度調べたつもりだが
cython全然わからんとです
超初心者スレで教えてもくれるかな

**デフォルトの名無しさん** · 2010/07/07(水) 22:45:35

Python3について調べてたらsuper()がキモくなってて吹いた。

http://lucumr.pocoo.org/2008/4/30/how-super-in-python3-works-and-why-its-retarded
↑にも書いてあるけど、関数定義中の__class__って何なん？第一引数をスタックフレームから取るっておいおい。

以下のクラス定義でFoo()foo()すると

class Foo:
　def foo(self):
　　print(locals()) #=> {'self': <__main__.Foo object> at ...>} # __class__いません
class Foo:
　def foo(self):
　　print(__class__) #=> <super: <class 'Foo'>, <Foo object>> # ちょww
_super = super
class Foo:
　def foo(self):
　　_super() #=> エラー # ちょww

いくらなんでもこの挙動はキモすぎだろ。たかがsuper()のためだけに。
最後のとか原因わかったとしても、難すぎる。
全くPythonicじゃない。こんなJavaに媚びるような仕様。

**デフォルトの名無しさん** · 2010/07/08(木) 00:21:03

Guidoパパ曰く：
> This whole movement to condemn super because it's not "pure" strikes
> me as wasted energy. That's my last word.

**265** · 2010/07/08(木) 01:08:18

>>266
英語力不足で意味が掴みづらいんだけど、

super()への批判は聞き飽きた。もう知らん。by Guido

って感じ？なんかGuidoらしくないなあ。俺みたいに批判してる人は
なんで今までわざわざself書いてきたんだろう、って気持ちになるんだよ。

通常の関数定義には__class__は現れなくて、メソッド定義中では
それが現れるってええ？メソッドがただのclass内で定義された関数っていう
整合性のためにself書いてたんだよって。

もちろんそれ以外にもselfなければデコレータがこれ程強力に
使われることもなかっただろうし、他にも利点はあるから
selfは必要だけど、それでもselfが必要な重要な理由の一つ
が消えちゃったんだ。

**デフォルトの名無しさん** · 2010/07/08(木) 01:47:54

メソッドの最初の引数にself付けるのも__class__が導入されたのも何が嫌なのか全く分からん

**デフォルトの名無しさん** · 2010/07/08(木) 03:33:46

Ruby そんなに嫌なら自分で新しい言語作れば良いのに
Python 我慢して使えよ
PHP 祈りなさい
Perl シラネ

**デフォルトの名無しさん** · 2010/07/08(木) 07:23:15

>>268
うーん。selfがキモくないと思うなら(俺はキモくないと思う)、
__class__はキモいと思えるはず。

__class__導入によって、selfが2.xに比べてキモくなったって話。
たぶんキモいのは多くのPythonistaが認めてる。さっきのサイトの書き込みとか見てると。
でも、それでもDRYなコードを書けるようにしたかったんだと思う。

あと、__class__って属性の方の__class__じゃないよ。ローカル変数の__class__ね。
属性の方は別にキモくないよ。

**デフォルトの名無しさん** · 2010/07/08(木) 07:30:11

一応コードで説明する
def foo(self):
　pass
class Foo:
　def foo(self):
　　pass
このとき、fooとFoo.fooが全く同じだったのが今までのPython。
Foo.fooはFoo名前空間の中にある「関数」に過ぎない。
Fooがインスタンス化されて、次みたいに呼び出される瞬間だけメソッドになるのが、
Pythonの実装方法
x = Foo()
x.foo # これはメソッドになる。(xが第一引数になる)

でも、Python3では、fooのローカルには存在しない変数__class__がFoo.fooの中に勝ってに
入ってる。

まあ、それだけの話だから、Pythonのオブジェクトシステムに興味ない人にとってはどうでも
いいかもね。俺はキモくてしかたないわ。

**デフォルトの名無しさん** · 2010/07/08(木) 22:36:37

>>270-271
ありがとう。意味が分かった。
確かにこれはキモい。

けど、キモくしてまで__class__を入れる理由ってあるの？

**デフォルトの名無しさん** · 2010/07/08(木) 23:03:11

無引数super()の実装に__class__が必要。
Pythonには自分を呼び出した元の関数のローカル変数を参照する機能が、
CレベルでもPythonレベルでもある。

__class__があれば、super()内から、クラスとselfが参照できるから、
そのクラスの__bases__からスーパークラスを参照してそれとselfを結びつけられる。

無引数super()が必要な理由は、DRYのためだけだと思う。確かにLLなのにDRYの点で
Javaなんかに負けるのは許されないことだったのかもしれない。

言語仕様を汚すぐらいならキーワードにしちまえみたいな意見もあったみたいだけど、
多重継承のあるPythonでは引数有りsuper()もサポートしたいし互換性あるし
みないなところで、こうなった。

俺はこのsuper()は関数に見せかけたキーワードだと思うことにした。
そうすれば、x=superとかしたときにx()が動作しないのにまだ納得がいく。

さて、再びROMるか。

**デフォルトの名無しさん** · 2010/07/08(木) 23:34:59

>>273
なるほど。重ね重ねありがと。

self.super()だったらそんなにきもくないのに(・ω・`)

**デフォルトの名無しさん** · 2010/07/23(金) 01:41:10

http://github.com/methane/ipython
誰か実験台になっておくれ。

**デフォルトの名無しさん** · 2010/09/09(木) 23:10:09

早くコンパイラ作って下さいお願いします
自分の作ったプログラムが終わるのに、後1年かかるとか待ってられない

**デフォルトの名無しさん** · 2010/09/10(金) 06:07:32

それはプロファイル取ってチューニングして、という常道はすでにおこなっての話？

**デフォルトの名無しさん** · 2010/09/10(金) 06:27:43

つ Cython
つ PyPy-c-jit

**デフォルトの名無しさん** · 2010/09/13(月) 06:10:48

>>277
常時してるよ
かと言っても、シミュレーション行わないといけないから
ある程度早くなった段階で、実行して、実行中に改善して、
次、実行するときに少し早くなったのつかって、ってのを繰り返してる

>>278
Cythonは使ってる
下のやつは初耳調べてみます

プログラムをオブジェクト指向みたいに書いちゃったおかけで、その部分をCythonに直すのがよくわからない
あと、Cythonの関数？を呼び出す回数が多いから、まだ時間がかかる
全体的に関数使いすぎだけど、拡張性を高くしときたいからこれをinline化するのも何かあれな気もする
速度を早くすることに時間を費やしてばかりいられないのと、
自分が低脳なせいで改良の余地はまだまだあるのに、大して出来てない・・・って状況です

**デフォルトの名無しさん** · 2010/09/13(月) 08:06:20

Cythonなら、Pythonのコードの8割がそのまま動く（ジェネレータとかは動かない）し、
defをcdefに書き換えるとPythonの関数オブジェクトを作らず直接C言語の関数になる
から関数呼び出しも高速になる。

**デフォルトの名無しさん** · 2010/09/13(月) 09:10:07

>>280
cdefはpyxの中でしか呼べないから、
pyからpyxのdefを呼んで、pyx内で、cdefを呼んでる
うまく説明出来てないけど、今こうなってる。
全部pyxにしちゃえばいいんだけど、そうできないのがいくつかある

**デフォルトの名無しさん** · 2010/09/13(月) 10:24:07

素直にSwigこれ最強

**デフォルトの名無しさん** · 2010/09/14(火) 02:13:37

boost.python ....

**デフォルトの名無しさん** · 2010/09/16(木) 18:38:30

結構色々とあるんですね
まあ、しばらくはCythonしか手を出せないんですが…

Cythonのオブジェクトが良くわからん
cdef class abc:
　def aaa(self,val):
　　aaa_f(self,val)
　cdef aaa_f(self,val):
　　self.A = 0
　　self.B = []
　　self.C = val

aaa_f がありませんだってお

**デフォルトの名無しさん** · 2010/09/16(木) 22:58:34

>>284
CythonじゃなくてPythonでもそれはエラーになるだろ…

**デフォルトの名無しさん** · 2010/09/16(木) 23:35:08

>>285
Pythonだとこんな感じ
#abc.py
class abc:
　def aaa(self,val):
　　self.A = 0
　　self.B = []
　　self.B = val

特に実行エラーとかもなく普通動いてる
#main.py
neko=abc.abc()
neko.aaa(val)

こんな感じかな

**デフォルトの名無しさん** · 2010/09/16(木) 23:50:26

>>284
aaa_f は誰の持ち物？

**デフォルトの名無しさん** · 2010/09/16(木) 23:56:47

>>287
nekoちゃん

**デフォルトの名無しさん** · 2010/09/17(金) 00:03:00

>>287
クラスabcです

**デフォルトの名無しさん** · 2010/09/17(金) 00:04:07

>>289
答えでてんじゃん

**デフォルトの名無しさん** · 2010/09/17(金) 00:11:15

>>290
よくわからないです…
#main.py
neko=abc.abc()
neko.aaa(val)

で、
#abc.pyx
のaaaを呼び出して
abc.pyxで、aaa_fを呼び出してる

cdef class abc:
　cdef:
　　object A
とかも必要なのか…

**デフォルトの名無しさん** · 2010/09/17(金) 00:45:44

class Foo1:
　def aaa(self):
　　self.bbb(0)
　def bbb(self,val):
　　self.x = val

class Foo2:
　def aaa(self):
　　bbb(0)
　def bbb(self,val):
　　self.x = val

class Foo3:
　def aaa(self):
　　Foo3.bbb(self,0)
　def bbb(self,val):
　　self.x = val

どれなら動くと思う？

**デフォルトの名無しさん** · 2010/09/17(金) 01:27:04

ああなるほど
Foo1かな
Foo3もかな

**デフォルトの名無しさん** · 2010/10/05(火) 07:02:42

ここまで互換性が無いのに、仕様変更するのってが良い
規制で雁字搦めになって身動きが取れなくなってたりしなくて
これからも、互換性気にせず、ドンドン変更して欲しい
その上で、変換するものがあってくれれば

**デフォルトの名無しさん** · 2010/10/05(火) 12:30:45

Python3のタイミングで変数の型指定（静的型付け）を導入してくれれば明るい未来が開けたのに・・・

**デフォルトの名無しさん** · 2010/10/05(火) 14:34:31

>>295
それPythonじゃなくね？

**デフォルトの名無しさん** · 2010/10/05(火) 19:11:33

Javaでも使ってろ

**デフォルトの名無しさん** · 2010/10/05(火) 20:39:58

>>295
あるよ

**デフォルトの名無しさん** · 2010/10/09(土) 15:46:51

型指定すると何か良いことあるの？速度以外で

**デフォルトの名無しさん** · 2010/10/10(日) 00:48:13

>>299
潔癖（だと思い込んでる）Javaプログラマを取り込みやすくなる、とかw

ないな。JavaプログラマはJavaしか書こうとしないし、それしかできないw

**デフォルトの名無しさん** · 2010/10/10(日) 01:22:35

>>299
インテリセンスが賢くなる。

>>300
Javaプログラマにコンプレックスがあるの？

**デフォルトの名無しさん** · 2010/10/10(日) 01:30:34

>>301
コンプレックスというより、バカで使えない、というトラウマがあってw

**デフォルトの名無しさん** · 2010/10/10(日) 09:19:37

一山いくらのドカタとハッカーを一緒にするな！

**デフォルトの名無しさん** · 2010/10/10(日) 10:22:07

このスレ見てるとPythonももう終わったなって感じだな

**デフォルトの名無しさん** · 2010/10/10(日) 11:53:58

__class__きもいんだけど。

**デフォルトの名無しさん** · 2010/10/20(水) 04:03:55

どうでもいいニュース:
今日、Arch Linuxの/usr/bin/pythonがpython3になった。

**デフォルトの名無しさん** · 2010/10/20(水) 10:30:47

Arch使ってるような変態じゃなくて玄人連中は別に困りそうも無いから問題無い

**デフォルトの名無しさん** · 2010/10/20(水) 13:26:33

debianは未だに（ｒｙ

**デフォルトの名無しさん** · 2010/10/20(水) 13:54:18

OSが勝手に3採用するのは困る

**デフォルトの名無しさん** · 2010/10/21(木) 00:22:52

どうせ2もpython2とかいう名前で入れられるんだろ？

**デフォルトの名無しさん** · 2010/10/21(木) 08:31:20

さっさと3に移行しろよクズども

**デフォルトの名無しさん** · 2010/10/21(木) 10:35:49

Python3の旅はこれからだ！
グイド先生の次回作、Python4にご期待ください。

**デフォルトの名無しさん** · 2010/10/21(木) 13:57:52

Djangoが使えるようになったら移行する > 3

**デフォルトの名無しさん** · 2010/10/21(木) 15:13:32

Python素人だけれども、
ユニコード文字列とかのややこしさがなくていいなと思って3.1をインストールしたんだが、
間に合ううちに2.7に切り替えるべきか？　それともどうせ通る道と受け入れるべきか？

**デフォルトの名無しさん** · 2010/10/21(木) 15:47:52

必要になったら2.xをいれればいいさ

**デフォルトの名無しさん** · 2010/10/21(木) 18:53:46

>>314
3rdパーティのライブラリが使いたくなったらPython2.xへ。

**デフォルトの名無しさん** · 2010/10/21(木) 22:39:06

必要になったら3.xをいれればいいさ
5年後ぐらいにはそうなるよきっと

**デフォルトの名無しさん** · 2010/10/21(木) 23:15:30

Google App Engine(とWSGI準拠のアプリケーション)が
3に対応したら必要性で周りのライブラリも加速するんじゃねぇかなーと思う

**デフォルトの名無しさん** · 2010/10/21(木) 23:16:58

3.2から一気に加速するよ。

**デフォルトの名無しさん** · 2010/10/22(金) 00:23:15

２から３に引っ越すメリットってなに？

**デフォルトの名無しさん** · 2010/10/22(金) 00:38:56

自己満足

**デフォルトの名無しさん** · 2010/10/22(金) 00:57:04

俺ってすごい感

**デフォルトの名無しさん** · 2010/10/22(金) 21:19:58

文字コード関連のエラーを見ないで済む

**デフォルトの名無しさん** · 2010/10/23(土) 00:08:54

嘘つくな。
UnicodeDecodeErrorは相変わらず出るぞ。

**デフォルトの名無しさん** · 2010/10/23(土) 00:37:33

ということはつまり２から３に引っ越すメリットってなに？

**デフォルトの名無しさん** · 2010/10/23(土) 01:25:56

将来にわたって比較的安心につかえる。
現時点でのメリットはそれしかない。

**デフォルトの名無しさん** · 2010/10/23(土) 09:11:21

>>324
そりゃ、出るには出るよ。

**デフォルトの名無しさん** · 2010/10/23(土) 20:45:30

>>326
ｸｸｸｯ, ﾊﾀｼﾃｿｳｶﾅとなりそうで怖い

**デフォルトの名無しさん** · 2010/10/24(日) 03:18:33

初心者ならいいけど、
ある程度の経験者でUnicodeDecodeErrorと格闘してるような奴は、
基礎を固めずに、行き当たりばったりでプログラムを書いてるんでしょ。

**デフォルトの名無しさん** · 2010/10/24(日) 03:37:10

いちいち u'' を書かなくて良くなったんだってね
2.x の unicode = 3.x の string
2.x の string = 3.x の bytearray
っていう認識で桶？

**デフォルトの名無しさん** · 2010/10/24(日) 03:48:05

俺はその認識。

**デフォルトの名無しさん** · 2010/10/24(日) 09:25:20

>>329
そういう基礎や定石的な対処法って何に書いてあるものなんだ？