X
【実験台】 Python 3.0 のお勉強 Part 1 【非互換】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2009/02/19(木) 22:30:15
Python 3.0 は隔離スレを作るべきだと思うのは俺だけかな？
そもそもあれは実用で使うには時期が早すぎるわけで、ここで
普通に語られても困る。
--------
別に
--------
細分化する必要性が全く感じられない。
各自がレスの内容を収拾選択すればいいだけ。
0471デフォルトの名無しさん
垢版 |
2012/10/05(金) 12:19:15.91
世の中的に３系イランモードなんかいな。
個人的には慣れてしまえば使いやすくていいもんだと思うから
はよ３系が主流になってほしい。
0472デフォルトの名無しさん
垢版 |
2012/10/05(金) 13:52:59.04
u付けて2でも動くよ〜
って喜んでる見たいだけどさ
2で動くんだったら3要らなくね？
ってなるよね
0473デフォルトの名無しさん
垢版 |
2012/10/05(金) 14:50:40.66
>>468
from __future__ import unicode_literals があるので
新規で両対応のコードを書くならそっち使う。

3.3では u"" は何もしないので、わざわざ使う利点はない。
3.2ではエラーになるので、寧ろ互換性を損ねてる。
0475デフォルトの名無しさん
垢版 |
2012/10/06(土) 13:00:56.12
u付き復活とかなんか必死だなとは思った

3のみ対応の素敵ライブラリでも出てこないと使う気が起こらない
そういうのもう出てたりしないのかな
0476デフォルトの名無しさん
垢版 |
2012/10/06(土) 13:16:55.44
いちおう3.3が2系を完全に切り離したリリース（今後２系はもうリリースしない）
と言われているけどな。ある意味やっとこさスタートラインともいえるが、どうなんだろうな。
0477デフォルトの名無しさん
垢版 |
2012/10/06(土) 15:39:31.68
u付き認めると移植はしやすくなるかも知れないけど、
3への完全移行にはかえって仇になると思うな。
0478デフォルトの名無しさん
垢版 |
2012/10/06(土) 15:45:08.23
ひとつ復活を認めると、あれもこれもでガンガン不要として切り捨てたものが復活して
結局2と同じものになりそうだな
0479デフォルトの名無しさん
垢版 |
2012/10/06(土) 15:50:58.36
D言語のgdgdの再現プレイを見ているようだ
内部崩壊を狙う埋伏の毒が居るのかもしれん
0482デフォルトの名無しさん
垢版 |
2012/10/18(木) 10:06:35.39
3 対応ってライブラリもCバインディングが含んでたら
buildし直さないと使えないんだな

まだ archぐらいじゃないか
3系列を薦めてくるの。ここから移行にはもうしばらく時間は掛かりそうだ…
0485デフォルトの名無しさん
垢版 |
2012/10/19(金) 20:24:25.93
http://distrowatch.com/table.php?distribution=ubuntu

はじめにbuiltinで入ってるのは 2.7.3

あたらしいのを使いたいなら
$ sudo apt-get install python-3.2-dev
$ sudo apt-get install python-3.3-dev

もしくは python3-dev で 3.2 が入る

どのみち後からいれないと駄目だ。次と言うと 13.4 からか
3.2 と 3.3 の違いがよくわからんが…
0486デフォルトの名無しさん
垢版 |
2012/10/19(金) 21:05:49.65
http://cpplover.blogspot.jp/2012/10/ubuntu-1304raring-ringtail.html
>また当初、Ubuntu 12.10で、CanonicalはPython 3.2に移行し、Python 2系列は
>デフォルトではインストールしない予定だった。Python 3はPython 2に対して
>破壊的な変更を含んでいる。つまり、Canonicalが直接サポートするソフトウェア
>でPythonを使うものは、すべてコードをPython 3.2で動作するように移植しなけ
>ればならない。残念ながら、その移植作業は間に合わず

http://news.mynavi.jp/news/2012/10/19/181/
>Python のバージョンをPython 3.2へ移行
>標準のGNUツールチェインをGCC 4.7.2に変更
>標準のJavaツールチェインをOpenJDK7に変更

mynavi プレスリリースする前に確認しようよ
まだ移行してないし
0489デフォルトの名無しさん
垢版 |
2012/10/21(日) 20:20:59.58
これはいい変更。
>>> open("aho.txt")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'aho.txt'
0500デフォルトの名無しさん
垢版 |
2012/11/05(月) 17:30:30.21
よく考えたら、おっぱい見るのはそこらに画像が転がってるから簡単だった。
だから揉みたいが正解だな。
0503デフォルトの名無しさん
垢版 |
2012/11/06(火) 00:38:07.56
expess edition だと plugin 使えないかんな！
と py3k に移植完了したコードを 2.7系に戻すそんな本末転倒な場面もあったり

でも os だってダウングレード権とかある。そんな状況が発生するのも別段おかしく
0507デフォルトの名無しさん
垢版 |
2012/11/12(月) 09:58:16.07
■python3系のメリット
・文字コード周りがすっきり　unicode/str地獄に悩まされなくて済む
・今後便利な機能がどんどん実装される　個人的にイテレータ周りは相当良くなると思う
・パフォーマンスは最新3.3で2系をほぼ凌駕した　地味な所でどんどん性能改善してるので今後期待できる

■言語自体のデメリット
・ほぼ無し　あえて言えば人によってprint文が若干面倒に感じるぐらい　言語自体は間違いなく良くなってる

■2->3への移行に伴うデメリット
・現有資産の書き換えが必要　特に文字コード周りは大幅な書き換えが必要
・まだ3系に対応していないライブラリが多い
　著名どころでも非対応多いし、対応してても枯れてないのでおかしな動きしたり


適当だけどこんなところかな>>505
とにかく非対応ライブラリの問題が根深いですね
既に対応してるライブラリでもテキスト処理関係のライブラリはまだバグが多い(lxmlとか)
0508デフォルトの名無しさん
垢版 |
2012/11/12(月) 10:55:17.54
文字コード周りがすっきり　unicode/str地獄に悩まされなくて済む
はずなのに 2 からの移行で悩まされるのはほとんどこの問題とか
0510デフォルトの名無しさん
垢版 |
2012/11/12(月) 11:47:13.68
Python3の唯一のデメリットはまだ枯れてないことだな。

例えばPyArg_ParseTupleの引数 s と s* の区別がきちんとできないライブラリが
標準ライブラリにも混じってるから困る。
0513デフォルトの名無しさん
垢版 |
2012/11/19(月) 04:26:23.09
ぼくちんはwxPythonが3.3に対応したら移行するでち
それまでは2.7で頑張りますでち
0524デフォルトの名無しさん
垢版 |
2012/12/01(土) 23:23:18.77
辞書オブジェクトのキーを属性名、バリューを値に持つようなクラスってつくれますか？

d = {'hello', 'world'}
obj = X(d)
print(obj.hello) # world

こんな感じにしたいんですが・・・
0525デフォルトの名無しさん
垢版 |
2012/12/02(日) 00:04:21.12
class ReadOnlyAttr(dict):
　def __getattr__(self, key):
　　if key in self:
　　　return self[key]
　　raise AttributeError(key)

spam = ReadOnlyAttr(hello='world')
spam['ham'] = 'egg'
print(spam.hello, spam.ham)
0526525
垢版 |
2012/12/02(日) 00:07:43.12
あっ、別に読み取り専用ではなかった
0527デフォルトの名無しさん
垢版 |
2012/12/02(日) 21:51:37.27
読み取り専用辞書 types.MappingProxyType が 3.3 に入ったね
以前のdictproxyからの変更、インスタンスが作れるようになってる

もう一つ3.3の話題、丁度新しい型が追加されてた
クラスやnamedtuple等よりは辞書寄りで、単に辞書データへ属性アクセスしたい場合に使える

ns = types.SimpleNamespace(hello="world")
0528デフォルトの名無しさん
垢版 |
2012/12/02(日) 21:58:49.14
改善された点
__getattr__を使う方法や、インスタンスの __dict__ へ追加する方法では
名前空間を共有することになるので、他の属性との名前の衝突には注意が必要になるけど

SimpleNamespaceは __xxx__ 形式の属性しかないので、比較的運用が楽。
辞書が必要な場合は、ns.__dict__ が使える

従来の方法に対するデメリットは、サブクラス化してメソッド追加が（多分？）出来ない点
0529デフォルトの名無しさん
垢版 |
2012/12/03(月) 00:23:40.62
その他、用途別。辞書ライクなデータを属性アクセス可能にする方法

# A
color = {"red":0, "green":0, "blue":0, "alpha": 0}
みたいに、小規模・フィールドが固定なデータ構造だったら namedtuple

# B
フィールドは固定で、本来なら属性にする所だけど
数が多いので外部リソースから読み込んだりして一時的に辞書で扱ってるのを
纏めて属性アクセスできるようにしたい。用途的に名前衝突の心配がない場合

self.__dict__.update({"hello":"world"})
0536デフォルトの名無しさん
垢版 |
2012/12/09(日) 10:16:08.81
>>533
ＩｒｏｎＰｙｔｈｏｎはＰｙｔｈｏｎから標準モジュールを抜いて、.NET フレームワークが使えるようになっただけ。
PythonとC#を学んだ方がいい。
0537デフォルトの名無しさん
垢版 |
2012/12/09(日) 10:45:43.09
>>534
一時的な用途で属性アクセス専用なら使えるけど、あまり積極的にはお勧めしない。

汎用の辞書としては、__dict__が他の属性と混ざってるので、扱いが面倒になる => 辞書のメソッドが使いたい場合、シリアライズしたい場合等
この点、SimpleNamespaceの方では__dict__でクリーンな辞書を参照できる。

後、ユニークなクラスを作ることになるので、別のインスタンスを作っても共通の親が無く
isinstanceでの判別がしにくい等、細かい点で手間かかる事になるかもしれない。
0538デフォルトの名無しさん
垢版 |
2012/12/09(日) 11:33:07.76
__dict__と混ざるのはメリットでもあるしデメリットでもあるんじゃないの
後この手のコンテキストで型チェックってあんま意味がないような気がする
実行時例外をそのままスルーした方がいいような
>>535は一行とはいえ黒魔術的だからSimpleNamespaceの方がいいんだろうけど
0539デフォルトの名無しさん
垢版 |
2012/12/10(月) 05:44:35.09
用途を明確にしたほうがいいかな

汎用コンテナとして、辞書を属性アクセス可能に拡張するなら、
辞書のサブクラス作るのが順当なアプローチだと思うけど
データと属性の名前空間が混ざるのはデメリット

オブジェクトの属性を辞書で一括更新する場合は __dict__ を利用
但し、クラス変数だと __xxx__形式のメソッドが混ざってくるのと__dict__が dictproxy(mappingproxy) になるので
インスタンス変数の__dict__を利用する。
0540デフォルトの名無しさん
垢版 |
2012/12/10(月) 06:02:31.59
>>538

> 後この手のコンテキストで型チェックってあんま意味がないような気がする
> 実行時例外をそのままスルーした方がいいような

型チェックが冗長になる場面では基本的に同意だけど、
出来るけどやらないのと、そもそも出来ないには隔たりがある。

Duck-Typeの柔軟性を活かす為に、暗黙のインターフェースを用いる方法は、
抽象基底クラス(abc)を使うとインターフェースを明示できるようになるよ。
0546デフォルトの名無しさん
垢版 |
2013/01/18(金) 20:57:46.27
Python3の書籍なんて何冊もないんだから全部買え。
自分に合った本は自分でしか見つけられない。
0548デフォルトの名無しさん
垢版 |
2013/01/20(日) 16:47:44.97
ほとんどshift-jisなんだけど時々違う文字コードが紛れ込んで文字化けしてるbyte列をデコードしたいのですが
こういう文字列として不完全なbyte列をデコードする関数は標準にはありますか？
0550デフォルトの名無しさん
垢版 |
2013/01/21(月) 01:12:18.06
>>548
場所とエンコーディングが分かっているのならば自分でbyte列を分割して適切に
処理してやればいいんじゃないの

全自動でやってくれというのなら>>549の言うように無理だな
Shift_JISとして不正なbyte列を含んでいる場合はそこでデコードエラーになり、
その位置も取れる筈だけど、以下のような問題がある

1)人の目には明白に文字化けしているケースであっても常にShift_JISとして不正な
　byte列であるとは限らず、その場合は「何か問題がある」ことすら検出
　しようがない
2)文字化け部分が短い場合、自動でその文字エンコーディングを推測するのは
　非常に困難
0551デフォルトの名無しさん
垢版 |
2013/01/21(月) 23:47:35.90
まあ、完璧にやるのは無理としても、デコードエラーになったら違う文字コードを
試すとかしてそれなりにデコードするのは可能かもしれない。

でも、それ以前にそんなニッチな関数が「標準」にあると思う方がどうかしてる。
0553デフォルトの名無しさん
垢版 |
2013/01/22(火) 12:02:39.81
＞ほとんどshift-jisなんだけど時々違う文字コードが紛れ込んで
環境依存文字等では、shift-jisではエラーでもcp932だと通る事がある。
そういったケースではなく、まったく別の文字コードが紛れてる？

不完全な部分を正しいデコードしなくてもよいのであれば、
decodeの第二引数に'ignore'や'replace'を指定すると、
デコード出来ない文字は読み飛ばしたり適当な文字に置き換えて処理してくれる。
エラー関数はカスタマイズ可能なので、551の方法を試す枠組み自体は整ってる。詳しくはcodecsモジュール読んで。
0554デフォルトの名無しさん
垢版 |
2013/01/22(火) 13:15:07.10
エラーの時に別のエンコーディングを試すアプローチだけど
文字コードが混在したデータには使えなかった。エラーにならない文字だと単に文字化けする
0557デフォルトの名無しさん
垢版 |
2013/03/14(木) 14:15:02.51
# module file : MyClass.py

class Body:
　　pass

class MyClass(object):
　　def __init__(this):
　　　　body = Body()
　　　　body.x = 0
　　　　def SetX(x):
　　　　　　body.x = x
　　　　def GetX():
　　　　　　return body.x
　　　　this.SetX = SetX
　　　　this.GetX = GetX

def New():
　　return MyClass()

こうするほかにアクセス不能（？）なプライベートなプロパティをもつことは可能ですか？
0560デフォルトの名無しさん
垢版 |
2013/04/07(日) 22:48:20.16
Python 3.2.4 and 3.3.1 have been released

ttp://www.python.org/download/releases/3.2.4/
ttp://www.python.org/download/releases/3.3.1/
0565デフォルトの名無しさん
垢版 |
2013/05/24(金) 22:51:03.02
インストーラーへのリンクは本家へ直リンなので
ユーザー会がページを更新していないだけだと考えられる
0567デフォルトの名無しさん
垢版 |
2013/05/24(金) 23:27:08.67
>>565
ありがとっす
日本語パス上にあるスクリプトファイルを
起動できない事象を回避したいので早速本家からもらってくる

>>566
これは古かったですかスマンです
移行したとは気づかなかった…
0568デフォルトの名無しさん
垢版 |
2013/09/12(木) 09:34:12.71
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>python -V
Python 3.2.5

C:\>
0569デフォルトの名無しさん
垢版 |
2013/09/12(木) 14:04:29.96
おいなりさんでおいなりさんを露出
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況