TSpython 発言

Bruce. です。
スタイルとか流儀の問題もあると思うので、その場合はスルーしてください。

機械伯爵 さんは書きました:
> This article explains the new features in Python 3.0, compared to 2.6. Python 3.0, also known as “Python 3000” or “Py3K”, is the first ever intentionally backwards incompatible Python release.
> 　この記事は、Python 2.6と比較したPython 3.0の新機能について説明します。"Python 3000"および"Py3k"として知られているPython 3.0は、下位互換を意図的に除いたPythonの始めてのリリースです。

下位互換ではなく、後方互換のような?
まあ意味として通じなくはないし3kをそれまでのものの「上位バージョン」として
見ることができるのなら良いのかも。

始めて→初めて

Python 3.0, also known as “Python 3000” or “Py3K”
は
Python3000やPy3k*としても*知られている(呼ばれている)。ではないでしょうか。

> There are more changes than in a typical release, and more that are important for all Python users.
> ここには全てのPythonユーザにとって重要な、より多くの変更があります。

いつもあるような(typicalをこう訳すのはあれですが)リリースにあるよりも
たくさんの変更があり、またそのような変更はすべてのPythonユーザーにとって
重要なものです。
#この言い回しは改良の余地あり

>  
> Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much ? by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.
> にもかかわらず、変更を理解した後に、あなたは、Pythonが本当は概してすべてのその多くを変更しなかったと気付くでしょう。そして私達は、たいてい有名な困り事と醜いものを修正していて、たくさんの古い嫌なものを削除しています。

digesting the changes って「変更を理解」でいいんでしょうか?

we're mostly fixing well-known annoyances and warts, and removing a lot
of old cruft.
は
よく知られているannoyances と warts のほとんどを修正し、同時に数多くの
old cruft を取り除いています
な感じではないでしょうか。

> 
> This article doesn’t attempt to provide a complete specification of all new features, but instead tries to give a convenient overview. For full details, you should refer to the documentation for Python 3.0, and/or the many PEPs referenced in the text.
> この記事では、すべての新機能の完全な仕様を説明するつもりはありませんが、代わりに便利な概観を提示します。詳細については、あなたはPython 3.0のドキュメント、あるいはそこで参照されている多くのPEPを参照してください

you should refer の「あなた」は訳文には入れないで良いのではないでしょうか。
またわたしはこのshould を「〜すると良いでしょう」と訳したいですが、
その辺はお好みですので。
この文では原文のPEPsをPEPとしていますが、この後に出てくるのはPEPsとなっ
ていますね。
訳文ではsはつけない方が良いと思いますがこれも(ry

> 
> If you want to understand the complete implementation and design rationale for a particular feature, PEPs usually have more details than the regular documentation; but note that PEPs usually are not kept up-to-date once a feature has been fully implemented.
> あなたが、完全な実装と特定の機能のための設計原理を理解したいならば、PEPsは通常のドキュメントより多くの詳細な情報を持っています。ただし機能が完全に実装されたら、PEPsが普通アップデートしないことに注意してください。

PEPsが普通アップデートしないことに注意してください。
→
PEPは普通はアップデートされないことに注意してください。
#普通とPEPの順番を入れ替えるとかもありますがそこはそれ

> Due to time constraints this document is not as complete as it should have been.
> 時間的制約のため、この文書は（かくあるべきとされるほど）完全ではありません。
> 
> As always for a new release, the Misc/NEWS file in the source distribution contains a wealth of detailed information about every small thing that was changed.
> いつものように新しいリリースでは、ソースの配布物の中の『その他/ニュース』のファイルに、変更されたすべての小さなものに関する詳細な情報が満載されています。

Misc/NEWSってファイル名だから訳しちゃまずいのでは?


> 
> Common Stumbling Blocks
> 共通の障害
> 
> This section lists those few changes that are most likely to trip you up if you’re used to Python 2.5.
> このセクションでは、Python 2.5を使用しているほとんどの人がつまづく幾つかの変更点がリストアップされています。

Python 2.5を使ってきていたユーザーがつまずくであろういくつかの変更点をリ
ストアップしています。
とか。

> Old : print x , # Trailing comma suppresses newline
> New : print ( x , end = " " ) # Appends a space instead of a newline
> 旧：print x , # 末尾のコンマの改行を抑制
> 新：print ( x , end = " " ) # スペースの代わりに改行を付加 

末尾のカンマが改行を抑制
改行の代わりにスペースを付加

> Old : print # Prints a newline
> New : print () # You must call the function!
> 旧：print # 改行を出力
> 新：print() # 『print関数』を呼び出す必要があります印刷

印刷?

> You can also customize the separator between items, e.g.:
> print("There are <", 2**32, "> possibilities!", sep="")
> which produces:
> There are <4294967296> possibilities!
> アイテムとの間のセパレータをカスタマイズすることもできます

アイテムとの間の　→ アイテムとアイテムの間の、アイテム間の

> Note:
> 注記：
> 
> * The print() function doesn’t support the “softspace” feature of the old print statement. 
> print関数は、昔のprint文の特徴だったsoftspaceをサポートしていません。 

softspace を囲むクォートを取っちゃいけないような。
ってソフトスペースってなんですか?
ソフトハイフンみたいなものでしょうか?

> 
> For example, in Python 2.x, print "A\n", "B" would write "A\nB\n" ; but in Python 3.0, print("A\n", "B") writes "A\n B\n" .
> 例えばPython 2.xでは、
> 	print "A\n", "B"
> は
> 	"A\nB\n"
> を出力しましたが、Python 3.0では
> 	print("A\n", "B")
> は
> 	"A\n B\n"
> を出力します。

あー、これがソフトスペースなのね。
> 
> * Initially, you’ll be finding yourself typing the old print x a lot in interactive mode. Time to retrain your fingers to type print(x) instead!
> 最初あなたは、インタラクティブモードで何度も『print x』と打ってしまう（ことに気づく）でしょう。（しかし）時間が、あなたの指を（かわりに）『print(x)』（と打てるよう）に再教育するでしょう。
> 
> * When using the 2to3 source-to-source conversion tool, all print statements are automatically converted to print() function calls, so this is mostly a non-issue for larger projects.
> (2.x→3.0)のソース変換ツールである"2to3"を使うと、全print文が自動的にprint関数呼び出しに変換されます。よってこれは大部分の大きなプロジェクトにとって問題ではありません。

mostly を抜かしちゃいけないと思います。
「ほとんどすべて」と「すべて」はかなり違うわけで。


> 
> Views And Iterators Instead Of Lists
> リスト(list)の代りにビュー(view)と反復子(iterator)を

代わりに→代わりの、に代わる?


> * dict methods dict.keys() , dict.items() and dict.values() return “views” instead of lists.
> 辞書(dict)のメソッドのdict.keys, dict.items, dict.valuesは、リストの代りにビュー(view)を返します。
> 
> For example, this no longer works: k = d.keys();k.sort() .
> 例えば、こういった使い方は既にできません。
> 	k = d.keys()
> 	k.sort()

「既にできません」に違和感。
「もうできません」とか「もはやできません」のような。


> Use k = sorted(d) instead (this works in Python 2.5 too and is just as efficient).
> 代わりに、sorted(d)を使用します（これはPython 2.5以降でも動きます。

「以降」はいらないのでは。
2.5でも使うことができますよということではないでしょうか。
and is just as efficient はどうしますかね。


> 
> * Also, the dict.iterkeys() , dict.iteritems() and dict.itervalues() methods are no longer supported.
> また、dict.iterkeysとdict.iteritemsとdict.itervaluesメソッドは、もはやサポートされていません。

訳文の方で()が抜けているのは?

> 
> * map() and filter() return iterators. 
> map関数とfilter関数は、反復子(iterator)を返します。
> 
> If you really need a list, a quick fix is eg list(map(...)) , but a better fix is often to use a list comprehension (especially when the original code uses lambda ), or rewriting the code so it doesn’t need a list at all.
> もしあなたが本当にリストが必要なら、一番手っ取り早い方法はlist(map(...))などと修正することですが、一般的により良い修正は、しばしばリストの内包記法を用いることです（特に元のコードでlambdaが使用されているのなら）。そのようにコードを書き直せば、リスト（list関数?）は全く必要ありません。

or rewriting 〜なので、

list(map(...))のように修正するか、あるいは
リストを使っているコードをイテレーターを使うものに書き換える。そうすれば
(当然ですが)リストは不要になるという意味ではないでしょうか。

> 
> Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful).
> 特に変則的なmap関数（の濫用）は、関数に副作用を招きます。正しい変換は、普通のループを使用することです（どうせリストを作成するだけ無駄でしょうから）

これは Perlのvoid context におけるmap関数の使用と一緒で、
(mapに呼び出される)関数の副作用を目的としてmap()を使うのは tricky なもの
です(だから避けましょう)。
ということでしょう。
そういったものはmap()をつかうとリストを無駄に作成することになるので、
ふつーの for loop でやんなさいな。
と。

> * builtin.sorted() and list.sort() no longer accept the cmp argument providing a comparison function.
> sorted組み込み関数とlist.sortメソッドは、もはや『比較関数』を引数に取ることはできません。


> 
> Use the key argument instead.
> 代わりに『key』という名称のキーワード引数に（比較関数を）渡します。
> 
> NB the key and reverse arguments are now “keyword-only”.
> 注意：キーと逆ソート引数は、今や『キーワード引数のみ』です。
> 
> （訳注：sorted(list, reverse=True)とすると、逆順にソートできます(reverse=1でも可)）
> 
> * The cmp() function should be treated as gone, and the __cmp__() special method is no longer supported.
> cmp関数は動作できるように扱う必要があり、__cmp__特殊メソッドはもはやサポートされません。

treated as goneって「なくなったものと見なせ」ということでは。

> 
> Use __lt__() for sorting, __eq__() with __hash__() , and other rich comparisons as needed. (If you really need the cmp() functionality, you could use the expression (a > b) - (a < b) as the equivalent for cmp(a, b) .)
> ソーティング（整列）には__lt__メソッド、__eq__メソッド、__hash__メソッド、および必要に応じてその他の豊富な比較方法が用いられます（もし本当にcmp()が関数として必要なら、"(a > b)-(a < b)"をcmp(a, b)と等価のものとして用いることができます）

cmpのように三種類の値を返す機能が必要なら
(a > b)-(a < b)　を使えということでは。
#これ本当に-1, 0, 1に…なるのか。

> 
> Integers
> 整数
> 
> * PEP 0237 : Essentially, long renamed to int . That is, there is only one built-in integral type, named int ; but it behaves mostly like the old long type. 
> * PEP 0237: 基本的にlongがintへ改称されました。それは、『int』という名の唯一の組み込み整数型です。しかし、殆どの『long』型と同様に動作します。

longという名称だったものが int に改称され、
Pythonにある整数型は int ただ一つになりました。
intとは言っても旧来のlongとほぼ同様に動作します。

> 
> * PEP 0238 : An expression like 1/2 returns a float. 
> * PEP 0238 : 『1 / 2』のような式は、浮動小数点数(float)を返します。
> 
> Use 1//2 to get the truncating behavior.
> 切捨ての（動作を行った）結果を得るには、『1 // 2』を使用します。
> 
> (The latter syntax has existed for years, at least since Python 2.2.) 
> （後者の構文は、 Python 2.2以降の年から存在しています）
> 
> * The sys.maxint constant was removed, since there is no longer a limit to the value of integers. 
> sys.maxint定数は削除され、もはや整数値に上限はありません。
> 
> However, sys.maxsize can be used as an integer larger than any practical list or string index.
> しかしながらsys.maxsize定数は、現実的なリストや文字列の（最大）インデックスよりも大きい数値です。

(整数値に上限がなくなったので)sys.maxintはなくなったけれども
sys.maxsizeはまだ残っていて、リストや文字列のインデックスの最大値として
使えますよということでは。
整数に上限がないので「添え字の最大」の値というのは現実的な制約を除けば
存在しないのでその代わりということでしょうか。

> 
> It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options).
> これは、実装の『自然な』整数のサイズに適合する。そしてこれは、一般的に以前のリリースの同じプラットフォームのsys.maxintと同じである（なお、同一オプションでビルドされたものとする）

> * Python 3.0 uses the concepts of text and (binary) data instead of Unicode strings and 8-bit strings.
> Python 3.0では、『テキストと（バイナリ）データ』の概念を、『Unicode文字列と8ビット』の代わりに採用しています。
> 
> All text is Unicode; however encoded Unicode is represented as binary data.
> すべてのテキストはUnicodeです。しかしながら、Unicodeのエンコードされたバイナリデータとして表現されています。 
> 
> （訳注：UTF-8のこと）

encoded Unicode is represented as binary data
は
エンコードされたUnicode(encoded Unicode)はバイナリデータとして表現
(represent)されます。
では。

エンコードされたUnicodeってUTF-8でいいんでしょうか?



> This value-specific behavior has caused numerous sad faces over the years.
> この値固有の現象は、年間で数多くの悲劇に直面しています。

この場合の「固有」は変換対象に非ASCIIのものが存在しているかどうかに「依
存」するとかでよいような。


> 
> * As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change.
> この哲学的な変更の結果、ほぼ全てのUnicode、エンコーディング、またはバイナリデータを扱うコードが変更されなければならないでしょう。

「哲学的な変更」はうーーーん
背中がむずがゆくなるような。

> 
> The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text.
> この変更のほうがマシなのは、2.xの世界では、混同やテキストのエンコード、デコードに関するおびただしいバグがあるからです。

ここでunencoded をデコードとしているのは意図的ですか?
次のパラグラフでは「エンコードされていない」になってます。
there were numerous bugs having to do with mixing encoded and unencoded
text.
は、エンコードされたテキストとエンコードされていないテキストを混ぜて
扱わなければならなかったことに起因したバグが大量にあった。とか?

> 
> To be prepared in Python 2.x, start using unicode for all unencoded text, and str for binary or encoded data only.
> Python 2.xで用意すべきことは、エンコードされていない全てのテキストでUnicodeを使い始めることと、『str』はバイナリデータか、エンコードされたデータのみで使うことでしょう。
> 
> Then the 2to3 tool will do most of the work for you.
> 次に、 2to3ツールがあなたのために作業をほとんどやってくれます。

前段のテキストとバイナリを使い分けろを受けて、そうしておけば(Then)
2と3がよろしくやってくれますということかと。

> 
> * You can no longer use u"..." literals for Unicode text. However, you must use b"..." literals for binary data.
> あなたはもはや、 Unicodeテキストでu"..."リテラルを使用することはできません。しかしながら、バイナリデータにはb"..."リテラルを使わなければなりません。


> 
> * As the str and bytes types cannot be mixed, you must always explicitly convert between them.
> str型とbytes型が混同不可能なため、いつでも明示的に相互に変換する必要があります。 
> 
> Use str.encode() to go from str to bytes , and bytes.decode() to go from bytes to str .
> str.encodeメソッドを使えば、str型からbytes型に変換します。そしてbytes.decodeメソッドは、bytes型からstr型に変換します。
> 
> You can also use bytes(s, encoding=...) and str(b, encoding=...) , respectively.
> また、それぞれ
> 	bytes(s, encoding=...)
> や
> 	str(b, encoding=...)
> を使うこともできます。
> 
> * Like str , the bytes type is immutable. 
> str型と同様に、bytes型も不変型です。
> 
> There is a separate mutable type to hold buffered binary data, bytearray .
> 分割した可変型のバイナリデータバッファを保持するためには、bytearray型があります。
> 
> Nearly all APIs that accept bytes also accept bytearray .
> bytes型オブジェクトを受け入れるAPIは、ほぼ全てbytearray型オブジェクトを受け入れます。
> 
> The mutable API is based on collections.MutableSequence . 
> 可変型に対応するAPIは、collections.MutableSequenceに基づいています。
> 
> * All backslashes in raw string literals are interpreted literally. This means that '\U' and '\u' escapes in raw strings are not treated specially.
> raw文字列リテラル内のすべてのバックスラッシュ(日本語コードでは\)は、文字通りに解釈されます。つまり'\U'と'\u'も、raw文字列の中では特別扱いされません。
> 
> For example, r'\u20ac' is a string of 6 characters in Python 3.0, whereas in 2.6, ur'\u20ac' was the single “euro” character.
> 例えば、Python 2.6ではur'\u20ac'は１文字の『ユーロ記号（Ｃに＝のアレ）』であるのに対して、r'\u20ac'はPython 3.0では（文字どおり）６文字（扱い）です。
> 
>  (Of course, this change only affects raw string literals; the euro character is '\u20ac' in Python 3.0.)
> （もちろん、この変更はraw文字列だけに影響を与えます。『ユーロ記号』文字列は、Python 3.0でも'\u20ac'で表せます）
> 
> * The builtin basestring abstract type was removed.
> 組み込みのbasestring抽象型は削除されました。
> 
> Use str instead.
> かわりにstr型を使用してください。
> 
> （訳注：basestring型は、2.xでは8bit専用だったstr型とUnicode文字列を統合的に扱うために存在しました）
> 
> The str and bytes types don’t have functionality enough in common to warrant a shared base class.
> str型とbytes型は、基底クラスを共有するほどの共通機能を持っていません。
> 
> The 2to3 tool (see below) replaces every occurrence of basestring with str .
> 2to3ツール（下記参照）は、basestring型の全ての事項をstr型に置き換えます。
> 
> * Files opened as text files (still the default mode for open() ) always use an encoding to map between strings (in memory) and bytes (on disk).
> ファイルをテキストファイルとして開く(open関数のデフォルトのモード)時は常に、文字列(メモリ上)とバイト列(ディスク上)の間の対応のためにエンコーディングを行います。
> 
> Binary files (opened with a b in the mode argument) always use bytes in memory.
> バイナリファイル（a,b モード引数を使用して開いた）は常にメモリ内のバイト列を使用します。

with a b in the mode argument のaは不定冠詞では?

> 
> This means that if a file is opened using an incorrect mode or encoding, I/O will likely fail loudly, instead of silently producing incorrect data.
> つまり、もし、ファイルを開く時に不正なモードまたはエンコードが使用されると、I/Oは静かに不正なデータを作るかわりに、おそらく派手に失敗します。

エンコーディングとエンコードの使い分けはどのようにしていますか?
ここは「エンコーディング」で良いと思いますが。

> 
> It also means that even Unix users will have to specify the correct mode (text or binary) when opening a file.
> また、 Unixのユーザでも（テキストまたはバイナリ）のファイルを開くときには、正しいモードを指定する必要があることを意味します。

evenがついているので強調したいです。


> 
> There is a platform-dependent default encoding, which on Unixy platforms can be set with the LANG environment variable (and sometimes also with some other platform-specific locale-related environment variables).
> UNIX型プラットフォームに於いては、LANG環境変数をセットすることができるため、プラットフォーム依存のデフォルトのエンコーディングがあります（そして時には、いくつかの他のプラットフォーム固有のロケールに関連する環境変数によっても……）

カッコ内の注記はLANG環境変数の直後の方が良いような。
LC_ALLとかLC_COLLATEなどのことを指しているのでしょう?

> 
> In many cases, but not all, the system default is UTF-8; you should never count on this default.
> 多くの場合システムのデフォルトはUTF-8です……が……しかし、『全て』ではないので、デフォルトを当てにしないでください。 

UTF-8がデフォルトであることに依存すべきでないということかと。

> 
> Any application reading or writing more than pure ASCII text should probably have a way to override the encoding. There is no longer any need for using the encoding-aware streams in the codecs module.
> 幾つかのアプリケーションは、純粋なASCIIテキストを読み書きする以上にエンコーディングを上書きする方法がおそらくあります。もはやコーデックモジュールでエンコードを意識したストリームを扱う必要はありません。

Any application は「いくつかの」ではなくむしろ「すべての」では。
pure ASCIIの範囲を超えたテキストを読み書きするすべてのアプリケーションは
エンコーディングを overrideする手段を持たせるべきでしょう
(持たせた方が良いでしょう)。

encoding-aware を「エンコードを〜」とするのは…

> 
> * Filenames are passed to and returned from APIs as (Unicode) strings. This can present platform-specific problems because on some platforms filenames are arbitrary byte strings.
> ファイル名はAPIから(Unicode)文字列として渡され、返されます。これは現在、プラットフォーム固有の問題を生んでいます。なぜなら、いくつかのプラットフォームのファイル名は任意のバイト文字列だからです。

pass to APIs をAPIから渡されというのはなんか違和感が。


> 
> (On the other hand, on Windows filenames are natively stored as Unicode.) As a work-around, most APIs (eg open() and many functions in the os module) that take filenames accept bytes objects as well as strings, and a few APIs have a way to ask for a bytes return value. 
> （その一方で、ネイティブのWindowsファイル名をUnicodeとして格納されます)仕事回りでは、殆どのAPI(例えば、open関数やosモジュールの数多くの関数など)は、ファイル名を文字列よりバイト列オブジェクトで受け取ります。そして幾つかのAPIでは、バイト列を戻り値として求める方法があります。

前のパラグラフのようなことはあるけれども、Windowsでは
ファイル名はUnicodeとして natively store されてますよ
つーことですよね?
as a work-around は要するに「回避策」でいいのでは


> 
> Thus, os.listdir() returns a list of bytes instances if the argument is a bytes instance, and os.getcwdb() returns the current working directory as a bytes instance.
> 例えば、os.listdir関数は、もし、引き数がbytes型ならば、バイト列のリストを返します。そしてos.getcwdb関数は、現在の作業ディレクトリをバイト列で返します。

引き数→引数

> 
> Note that when os.listdir() returns a list of strings, filenames that cannot be decoded properly are omitted rather than raising UnicodeError .
> os.listdir関数が文字列のリストを戻す時に、適切にデコードされることができないファイル名が、UnicodeErrorを上る場合よりも、『忘れられること』に注意してください。

UnicodeError例外をraiseしないでエラーを無視しますということでは。

> 
> * Some system APIs like os.environ and sys.argv can also present problems when the bytes made available by the system is not interpretable using the default encoding.
> システムによって使用可能にされたバイト列が、デフォルトのエンコーディングを使って、解釈可能でない時、os.environとsys.argvのような幾つかのシステムAPIは、問題をおこす可能性があります。
> 
> Setting the LANG variable and rerunning the program is probably the best approach. 
> LANG変数を設定し、プログラムを再実行することが、たぶん最もよいアプローチでしょう。
> 
> * PEP 3138 : The repr() of a string no longer escapes non-ASCII characters.
> * PEP 3138 : 文字列のreprは、もはや非ASCII文字をエスケープしたりしません。
> 
> It still escapes control characters and code points with non-printable status in the Unicode standard, however.
> しかしながら、ユニコード標準の中で印刷可能でないステータスを持つコードポイントと制御文字は、エスケープされることになります。
> 
> * PEP 3120 : The default source encoding is now UTF-8. 
> * PEP 3120：デフォルトのソースのエンコードは、現在UTF-8です。

ソースコードで使われるデフォルトのエンコーディングはUTF-8となりました。
とか。


-- 
木村浩一/KIMURA Koichi
 I thought what I'd do was, I'd pretend I was one of those deaf-mutes or
shoud I?
 mail kbk at kt.rim.or.jp
 web  www.kt.rim.or.jp/~kbk/zakkicho/index.html