design.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2021, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
# Translators:
# tomo, 2019
# Hiroyuki Kurosawa <kh99mail@gmail.com>, 2019
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.7\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-01-01 16:02+0000\n"
"PO-Revision-Date: 2019-09-01 02:43+0000\n"
"Last-Translator: Hiroyuki Kurosawa <kh99mail@gmail.com>, 2019\n"
"Language-Team: Japanese (https://www.transifex.com/python-doc/teams/5390/"
"ja/)\n"
"Language: ja\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"

#: ../../faq/design.rst:3
msgid "Design and History FAQ"
msgstr "デザインと歴史 FAQ"

#: ../../faq/design.rst:6
msgid "Contents"
msgstr "内容"

#: ../../faq/design.rst:11
msgid "Why does Python use indentation for grouping of statements?"
msgstr "Python はなぜ文のグループ化にインデントを使うのですか？"

#: ../../faq/design.rst:13
msgid ""
"Guido van Rossum believes that using indentation for grouping is extremely "
"elegant and contributes a lot to the clarity of the average Python program. "
"Most people learn to love this feature after a while."
msgstr ""
"Guido van Rossum の信じるところによれば、インデントによるグループ化は非常にエ"
"レガントで、普通の Python プログラムを大いに読みやすくします。しばらくすれば"
"ほとんどの人はこの仕様を気に入るようになります。"

#: ../../faq/design.rst:17
msgid ""
"Since there are no begin/end brackets there cannot be a disagreement between "
"grouping perceived by the parser and the human reader.  Occasionally C "
"programmers will encounter a fragment of code like this::"
msgstr ""
"開始/終了の括弧がないので、構文解析器と人間の読者の間にグループ化の解釈の違い"
"は起こりえません。時折、C のプログラマはこのようなコード片に出くわします::"

#: ../../faq/design.rst:26
msgid ""
"Only the ``x++`` statement is executed if the condition is true, but the "
"indentation leads you to believe otherwise.  Even experienced C programmers "
"will sometimes stare at it a long time wondering why ``y`` is being "
"decremented even for ``x > y``."
msgstr ""
"この条件文が真の時のみ実行されるのは ``x++`` 文だけですが、このインデントでは"
"誤解を招きます。経験を積んだ C プログラマでさえ、 ``y`` が ``x > y`` の時にも"
"デクリメントされるのはなぜか分からず長いこと立ち止まることがあるでしょう。"

#: ../../faq/design.rst:31
msgid ""
"Because there are no begin/end brackets, Python is much less prone to coding-"
"style conflicts.  In C there are many different ways to place the braces. If "
"you're used to reading and writing code that uses one style, you will feel "
"at least slightly uneasy when reading (or being required to write) another "
"style."
msgstr ""
"開始/終了の括弧がないので、Python はコーディングスタイルの対立が非常に起こり"
"にくくなります。C では多様なカッコの置き方があります。一つのスタイルでのコー"
"ドの読み書きに慣れてしまうと、他のスタイルを読む (あるいは書く必要がある) と"
"きにむずむずするでしょう。"

#: ../../faq/design.rst:36
msgid ""
"Many coding styles place begin/end brackets on a line by themselves.  This "
"makes programs considerably longer and wastes valuable screen space, making "
"it harder to get a good overview of a program.  Ideally, a function should "
"fit on one screen (say, 20--30 lines).  20 lines of Python can do a lot more "
"work than 20 lines of C.  This is not solely due to the lack of begin/end "
"brackets -- the lack of declarations and the high-level data types are also "
"responsible -- but the indentation-based syntax certainly helps."
msgstr ""
"多くのコーディングスタイルは begin/end の括弧にそれぞれ一行を使います。これで"
"はプログラムは冗長になって画面を浪費し、プログラムの見通しが悪くなります。一"
"つの関数は一画面 (例えば 20 から 30 行) に収めるのが理想です。20 行の Python "
"は 20 行の C よりもはるかに多くの作業ができます。これは begin/end の括弧がな"
"いからだけではありません -- 宣言が不要なことや高レベルなデータ型もその理由で"
"す -- が、インデントに基づく構文は確かに役に立っています。"

#: ../../faq/design.rst:46
msgid "Why am I getting strange results with simple arithmetic operations?"
msgstr "なぜ単純な算術演算が奇妙な結果になるのですか？"

#: ../../faq/design.rst:48
msgid "See the next question."
msgstr "次の質問を参照してください。"

#: ../../faq/design.rst:52
msgid "Why are floating-point calculations so inaccurate?"
msgstr "なんで浮動小数点数の計算はこんなに不正確なんですか？"

#: ../../faq/design.rst:54
msgid "Users are often surprised by results like this::"
msgstr "ユーザーはよく次のような結果に驚きます::"

#: ../../faq/design.rst:59
msgid ""
"and think it is a bug in Python.  It's not.  This has little to do with "
"Python, and much more to do with how the underlying platform handles "
"floating-point numbers."
msgstr ""
"そしてこれが Python のバグだと考えます。が、これはバグではありません。この結"
"果に Python はほとんど関与しておらず、むしろ基底のプラットフォームによる浮動"
"小数点数の扱い方が関与しています。"

#: ../../faq/design.rst:63
msgid ""
"The :class:`float` type in CPython uses a C ``double`` for storage.  A :"
"class:`float` object's value is stored in binary floating-point with a fixed "
"precision (typically 53 bits) and Python uses C operations, which in turn "
"rely on the hardware implementation in the processor, to perform floating-"
"point operations. This means that as far as floating-point operations are "
"concerned, Python behaves like many popular languages including C and Java."
msgstr ""
"CPython における :class:`float` 型は記憶に C 言語の ``double`` 型を使いま"
"す。 :class:`float` オブジェクトの値は固定精度 (典型的には 53 bit) の 2 進浮"
"動小数点数として格納され、 Python はプロセッサのハードウェアが実装している C "
"言語上の演算を使います。つまり、浮動小数点数に関して Python は C 言語や Java "
"のような多くの一般的な言語と同じように振る舞います。"

#: ../../faq/design.rst:70
msgid ""
"Many numbers that can be written easily in decimal notation cannot be "
"expressed exactly in binary floating-point.  For example, after::"
msgstr ""
"10 進数で簡単に書ける多くの数が、2 進浮動小数点数では正確に表すことができませ"
"ん。例えばこうすると::"

#: ../../faq/design.rst:75
msgid ""
"the value stored for ``x`` is a (very good) approximation to the decimal "
"value ``1.2``, but is not exactly equal to it.  On a typical machine, the "
"actual stored value is::"
msgstr ""
"``x`` に保存された値は 10 進数の ``1.2`` の (とても高い精度の) 近似値であっ"
"て、厳密な ``1.2`` ではありません。一般的なコンピューターでは、実際に格納され"
"る値は::"

#: ../../faq/design.rst:81
msgid "which is exactly::"
msgstr "で、正確には次の値です::"

#: ../../faq/design.rst:85
msgid ""
"The typical precision of 53 bits provides Python floats with 15--16 decimal "
"digits of accuracy."
msgstr ""
"53bit の典型的な精度は、Python の float に 10 進数で 15〜16桁の精度を与えま"
"す。"

#: ../../faq/design.rst:88
msgid ""
"For a fuller explanation, please see the :ref:`floating point arithmetic "
"<tut-fp-issues>` chapter in the Python tutorial."
msgstr ""
"詳しくは、Python チュートリアルの :ref:`floating point arithmetic <tut-fp-"
"issues>` の章を参照してください。"

#: ../../faq/design.rst:93
msgid "Why are Python strings immutable?"
msgstr "なぜ Python の文字列はイミュータブルなのですか？"

#: ../../faq/design.rst:95
msgid "There are several advantages."
msgstr "これにはいくつかの利点があります。"

#: ../../faq/design.rst:97
msgid ""
"One is performance: knowing that a string is immutable means we can allocate "
"space for it at creation time, and the storage requirements are fixed and "
"unchanging.  This is also one of the reasons for the distinction between "
"tuples and lists."
msgstr ""
"一つはパフォーマンスです。文字列がイミュータブルなら、生成時に領域を割り当て"
"ることができるので、必要な記憶域は固定されて、変更されません。これはタプルと"
"リストを区別する理由の一つでもあります。"

#: ../../faq/design.rst:102
msgid ""
"Another advantage is that strings in Python are considered as \"elemental\" "
"as numbers.  No amount of activity will change the value 8 to anything else, "
"and in Python, no amount of activity will change the string \"eight\" to "
"anything else."
msgstr ""
"他の利点は、Python の文字列は数と同じくらい \"基本的\" なものと考えられること"
"です。8 という値を他の何かに変える手段が無いように、文字列 \"eight\" を他の何"
"かに変える手段も無いのです。"

#: ../../faq/design.rst:110
msgid "Why must 'self' be used explicitly in method definitions and calls?"
msgstr ""
"なぜメソッドの定義や呼び出しにおいて 'self' を明示しなければならないのです"
"か？"

#: ../../faq/design.rst:112
msgid ""
"The idea was borrowed from Modula-3.  It turns out to be very useful, for a "
"variety of reasons."
msgstr ""
"このアイデアは Modula-3 から取り入れられました。これは様々な理由からとても便"
"利だと言えます。"

#: ../../faq/design.rst:115
msgid ""
"First, it's more obvious that you are using a method or instance attribute "
"instead of a local variable.  Reading ``self.x`` or ``self.meth()`` makes it "
"absolutely clear that an instance variable or method is used even if you "
"don't know the class definition by heart.  In C++, you can sort of tell by "
"the lack of a local variable declaration (assuming globals are rare or "
"easily recognizable) -- but in Python, there are no local variable "
"declarations, so you'd have to look up the class definition to be sure.  "
"Some C++ and Java coding standards call for instance attributes to have an "
"``m_`` prefix, so this explicitness is still useful in those languages, too."
msgstr ""
"まず、ローカル変数ではなく、メソッドやインスタンス属性を扱っていることがより"
"明確になります。 ``self.x`` や ``self.meth()`` と書いてあれば、そのクラスの定"
"義を憶えていなくても、それがインスタンス変数やメソッドであることは明らかで"
"す。C++ では、(グローバルが滅多になかったり、簡単に見分けがつくなら) ローカル"
"変数宣言がないことからある程度わかるでしょう。-- しかし Python にはローカル変"
"数宣言がないので、クラス定義を調べて確かめなくてはなりません。C++ や Java の"
"コーディングスタンダードに、インスタンス属性に ``m_`` 接頭辞をつけるものがあ"
"るので、この明示性はそれらの言語においても有用です。"

#: ../../faq/design.rst:125
msgid ""
"Second, it means that no special syntax is necessary if you want to "
"explicitly reference or call the method from a particular class.  In C++, if "
"you want to use a method from a base class which is overridden in a derived "
"class, you have to use the ``::`` operator -- in Python you can write "
"``baseclass.methodname(self, <argument list>)``.  This is particularly "
"useful for :meth:`__init__` methods, and in general in cases where a derived "
"class method wants to extend the base class method of the same name and thus "
"has to call the base class method somehow."
msgstr ""
"第二に、特定のクラスからメソッドを明示的に参照または呼び出ししたい時に、特別"
"な構文が必要なくなります。C++ では、派生クラスでオーバーライドされた基底クラ"
"スからメソッドを使うには、 ``::`` 演算子を使わなければなりません。 -- Python "
"では、 ``baseclass.methodname(self, <argument list>)`` と書けます。これは特"
"に、 :meth:`__init__` メソッドに便利ですし、派生クラスのメソッドが、基底クラ"
"スにある同じ名前のメソッドを拡張するために、基底クラスのメソッドをどうにかし"
"て呼び出したい時にも便利です。"

#: ../../faq/design.rst:134
msgid ""
"Finally, for instance variables it solves a syntactic problem with "
"assignment: since local variables in Python are (by definition!) those "
"variables to which a value is assigned in a function body (and that aren't "
"explicitly declared global), there has to be some way to tell the "
"interpreter that an assignment was meant to assign to an instance variable "
"instead of to a local variable, and it should preferably be syntactic (for "
"efficiency reasons).  C++ does this through declarations, but Python doesn't "
"have declarations and it would be a pity having to introduce them just for "
"this purpose.  Using the explicit ``self.var`` solves this nicely.  "
"Similarly, for using instance variables, having to write ``self.var`` means "
"that references to unqualified names inside a method don't have to search "
"the instance's directories.  To put it another way, local variables and "
"instance variables live in two different namespaces, and you need to tell "
"Python which namespace to use."
msgstr ""
"最後に、インスタンス変数に対する、代入の構文の問題を解決できます。Python の"
"ローカル変数は、関数の中で (global が明示的に宣言されることなく) 値が代入され"
"た変数 (と定義されています！) です。なので、ある代入が意図するのが、ローカル"
"変数へではなくインスタンス変数への代入であると、インタプリタが判断する手段が"
"必要です。そしてそれは構文を見るだけで分かる方が (効率が) 良いのです。C++ で"
"はその区別を宣言時に行いますが、Python では宣言がないので、この方法でしか区別"
"できなかったら残念です。 ``self.var`` を明示すればうまく解決できます。同様"
"に、インスタンス変数を使うのにも ``self.var`` と書かなければならないので、メ"
"ソッドの中の self が付いていない名前への参照は、そのインスタンスのディレクト"
"リを検索するまでもなくローカル変数とわかります。別の言い方をすれば、ローカル"
"変数とインスタンス変数は二つの異なる名前空間に存在し、Python にどちらの名前空"
"間を使うかを伝えなくてはならないのです。"

#: ../../faq/design.rst:150
msgid "Why can't I use an assignment in an expression?"
msgstr "式中で代入ができないのはなぜですか？"

#: ../../faq/design.rst:152
msgid ""
"Many people used to C or Perl complain that they want to use this C idiom:"
msgstr "C や Perl に慣れた多くの人は、C のこの慣用句を使いたいと訴えます:"

#: ../../faq/design.rst:160
msgid "where in Python you're forced to write this::"
msgstr "Python ではこう書かなくてはなりません::"

#: ../../faq/design.rst:168
msgid ""
"The reason for not allowing assignment in Python expressions is a common, "
"hard-to-find bug in those other languages, caused by this construct:"
msgstr ""
"Python の式中での代入を許さない理由は、この構造によって起こる、他の言語ではあ"
"りがちで見つけづらいバグです:"

#: ../../faq/design.rst:180
msgid ""
"The error is a simple typo: ``x = 0``, which assigns 0 to the variable "
"``x``, was written while the comparison ``x == 0`` is certainly what was "
"intended."
msgstr ""
"このエラーは単純なタイプミスで、本当にやりたかったのは ``x == 0`` の比較です"
"が、 ``x = 0`` と書いてしまい、変数 ``x`` に 0 を代入しています。"

#: ../../faq/design.rst:183
msgid ""
"Many alternatives have been proposed.  Most are hacks that save some typing "
"but use arbitrary or cryptic syntax or keywords, and fail the simple "
"criterion for language change proposals: it should intuitively suggest the "
"proper meaning to a human reader who has not yet been introduced to the "
"construct."
msgstr ""
"提案された代替案はたくさんあります。多くの案はタイプ数を少し節約しますが、勝"
"手だったり意味不明だったりする構文や予約語を使い、言語変更の提案の簡潔さの基"
"準を満たしていません。構造の説明をされていない人間の読者に、正しい意味を直感"
"的に示す物であるべきです。"

#: ../../faq/design.rst:188
msgid ""
"An interesting phenomenon is that most experienced Python programmers "
"recognize the ``while True`` idiom and don't seem to be missing the "
"assignment in expression construct much; it's only newcomers who express a "
"strong desire to add this to the language."
msgstr ""
"面白いことに、熟練した Python プログラマは ``while True`` イディオムを受け入"
"れていて、式構造中の代入がなくてもそれほど苦労しないようです。Python にそれを"
"強く求めるのは新人だけです。"

#: ../../faq/design.rst:193
msgid ""
"There's an alternative way of spelling this that seems attractive but is "
"generally less robust than the \"while True\" solution::"
msgstr ""
"以下の方法でもこれを綴ることができて、魅力的そうですが、堅牢さでは \"while "
"True\" を使う方法に劣ることが多いです::"

#: ../../faq/design.rst:201
msgid ""
"The problem with this is that if you change your mind about exactly how you "
"get the next line (e.g. you want to change it into ``sys.stdin.readline()``) "
"you have to remember to change two places in your program -- the second "
"occurrence is hidden at the bottom of the loop."
msgstr ""
"この方法の問題は、次の行を取得する方法を変えたくなったとき (``sys.stdin."
"readline()`` に変更したい時など) にプログラムの二箇所を変えなくてはならないこ"
"とです -- 二つ目の場所はループの最後に隠れています。"

#: ../../faq/design.rst:206
msgid ""
"The best approach is to use iterators, making it possible to loop through "
"objects using the ``for`` statement.  For example, :term:`file objects <file "
"object>` support the iterator protocol, so you can write simply::"
msgstr ""
"一番いい方法はイテレータを使って、 ``for`` 文でオブジェクトを通してループさせ"
"ることです。例えば、 :term:`ファイルオブジェクト <file object>` はイテレータ"
"プロトコルをサポートしているので、単純にこう書けます::"

#: ../../faq/design.rst:216
msgid ""
"Why does Python use methods for some functionality (e.g. list.index()) but "
"functions for other (e.g. len(list))?"
msgstr ""
"Python にメソッドを使う機能 (list.index() 等) と関数を使う機能 (len(list) "
"等) があるのはなぜですか？"

#: ../../faq/design.rst:218
msgid "As Guido said:"
msgstr "Guidoいわく："

#: ../../faq/design.rst:220
msgid ""
"(a) For some operations, prefix notation just reads better than postfix -- "
"prefix (and infix!) operations have a long tradition in mathematics which "
"likes notations where the visuals help the mathematician thinking about a "
"problem. Compare the easy with which we rewrite a formula like x*(a+b) into "
"x*a + x*b to the clumsiness of doing the same thing using a raw OO notation."
msgstr ""
"(a) 幾つかの演算では、接頭辞は接尾辞よりも単純に読みやすいからです。接頭辞"
"（そして接中辞！）による演算は数学において長い歴史があり、そこでは課題に対す"
"る数学者の思考を視覚的に助けるような記法が好まれます。x*(a+b)をx*a + x*bに書"
"き換える容易さと、それと同じことを純粋なオブジェクト指向の記法で行う煩わしさ"
"を比較してみてください。"

#: ../../faq/design.rst:227
msgid ""
"(b) When I read code that says len(x) I *know* that it is asking for the "
"length of something. This tells me two things: the result is an integer, and "
"the argument is some kind of container. To the contrary, when I read x."
"len(), I have to already know that x is some kind of container implementing "
"an interface or inheriting from a class that has a standard len(). Witness "
"the confusion we occasionally have when a class that is not implementing a "
"mapping has a get() or keys() method, or something that isn't a file has a "
"write() method."
msgstr ""
"(b) len(x)というコードを読んだ時、私はそれが何かの長さを問うているのだなと知"
"ることができます。これは私に2つの事を知らせています。一つは結果が整数であるこ"
"と、そして引数は何らかのコンテナであることです。対して、x.len()を目にした場"
"合、私はその時点でxが何らかのコンテナであり、それが標準のlen()を持っているク"
"ラスを継承しているか、インターフェースを実装していることを知っている必要があ"
"ります。mappingを実装していないクラスがget()やkeys()メソッドを持っていたり、"
"fileでない何かがwrite()メソッドを持っているような混乱は時折見かけます。"

#: ../../faq/design.rst:254
msgid "https://mail.python.org/pipermail/python-3000/2006-November/004643.html"
msgstr ""
"https://mail.python.org/pipermail/python-3000/2006-November/004643.html"

#: ../../faq/design.rst:240
msgid "Why is join() a string method instead of a list or tuple method?"
msgstr ""
"join() がリストやタプルのメソッドではなく文字列のメソッドなのはなぜですか？"

#: ../../faq/design.rst:242
msgid ""
"Strings became much more like other standard types starting in Python 1.6, "
"when methods were added which give the same functionality that has always "
"been available using the functions of the string module.  Most of these new "
"methods have been widely accepted, but the one which appears to make some "
"programmers feel uncomfortable is::"
msgstr ""
"文字列は Python 1.6 から他の標準型に大きく近づきました。それ以前は常に "
"string モジュールの関数を使ってできていたことと同等の機能を持つメソッドがこの"
"時に追加されました。その新しいメソッドの多くは広く受け入れられましたが、一部"
"のプログラマに不快を感じさせていると思われるものがこれで::"

#: ../../faq/design.rst:250
msgid "which gives the result::"
msgstr "結果はこうなります::"

#: ../../faq/design.rst:254
msgid "There are two common arguments against this usage."
msgstr "この使い方には二つの議論があります。"

#: ../../faq/design.rst:256
msgid ""
"The first runs along the lines of: \"It looks really ugly using a method of "
"a string literal (string constant)\", to which the answer is that it might, "
"but a string literal is just a fixed value. If the methods are to be allowed "
"on names bound to strings there is no logical reason to make them "
"unavailable on literals."
msgstr ""
"一つ目は、「文字列リテラル (文字列定数) のメソッドを使うのは醜すぎる」という"
"ようなものです。確かにそうかも知れませんが、文字列リテラルは単なる固定された"
"値に過ぎないというのが答えです。文字列に束縛された名前にメソッドが許されるな"
"ら、リテラルに使えないようにする論理的な理由はないでしょう。"

#: ../../faq/design.rst:262
msgid ""
"The second objection is typically cast as: \"I am really telling a sequence "
"to join its members together with a string constant\".  Sadly, you aren't.  "
"For some reason there seems to be much less difficulty with having :meth:"
"`~str.split` as a string method, since in that case it is easy to see that ::"
msgstr ""
"二つ目の反対理由は、典型的には「私は実際、要素を文字列定数とともに結合させる"
"よう、シーケンスに命じているのだ」というものです。残念ながら、そうではないの"
"です。いくつかの理由から :meth:`~str.split` を文字列のメソッドとしておいた方"
"がはるかに簡単です。これを見ると分かりやすいでしょう ::"

#: ../../faq/design.rst:269
msgid ""
"is an instruction to a string literal to return the substrings delimited by "
"the given separator (or, by default, arbitrary runs of white space)."
msgstr ""
"これは文字列リテラルに対する、与えられたセパレータ (または、デフォルトでは任"
"意の空白文字の連続) で区切られた部分文字列を返せという指示です。"

#: ../../faq/design.rst:272
msgid ""
":meth:`~str.join` is a string method because in using it you are telling the "
"separator string to iterate over a sequence of strings and insert itself "
"between adjacent elements.  This method can be used with any argument which "
"obeys the rules for sequence objects, including any new classes you might "
"define yourself. Similar methods exist for bytes and bytearray objects."
msgstr ""
":meth:`~str.join` は、セパレータ文字列に、文字列のシーケンスをイテレートして"
"隣り合う要素の間に自身を挿入するように指示しているので、文字列のメソッドで"
"す。このメソッドは、独自に定義された新しいクラスを含め、シーケンスの規則を満"
"たすいかなる引数にも使えます。バイト列やバイト配列にも同様のメソッドがありま"
"す。"

#: ../../faq/design.rst:280
msgid "How fast are exceptions?"
msgstr "例外はどれくらい速いのですか？"

#: ../../faq/design.rst:282
msgid ""
"A try/except block is extremely efficient if no exceptions are raised.  "
"Actually catching an exception is expensive.  In versions of Python prior to "
"2.0 it was common to use this idiom::"
msgstr ""
"try/except ブロックは例外が送出されなければ極端に効率的です。実際に例外を捕捉"
"するのは高価です。Python 2.0 より前のバージョンでは、このイディオムを使うのが"
"一般的でした::"

#: ../../faq/design.rst:292
msgid ""
"This only made sense when you expected the dict to have the key almost all "
"the time.  If that wasn't the case, you coded it like this::"
msgstr ""
"これは、辞書がほとんどの場合にキーを持っていると予想できるときにのみ意味をな"
"します。そうでなければ、このように書きます::"

#: ../../faq/design.rst:300
msgid ""
"For this specific case, you could also use ``value = dict.setdefault(key, "
"getvalue(key))``, but only if the ``getvalue()`` call is cheap enough "
"because it is evaluated in all cases."
msgstr ""
"この特殊な場合では ``value = dict.setdefault(key, getvalue(key))`` も使えます"
"が、これは ``getvalue()`` 呼び出しが十分安価な場合に限ります。なぜならそれが"
"全ての場合に評価されるからです。"

#: ../../faq/design.rst:306
msgid "Why isn't there a switch or case statement in Python?"
msgstr "Python に switch や case 文がないのはなぜですか？"

#: ../../faq/design.rst:308
msgid ""
"You can do this easily enough with a sequence of ``if... elif... elif... "
"else``. There have been some proposals for switch statement syntax, but "
"there is no consensus (yet) on whether and how to do range tests.  See :pep:"
"`275` for complete details and the current status."
msgstr ""
"``if... elif... elif... else`` の繰り返しで簡単に同じことができます。switch "
"文の構文に関する提案がいくつかありましたが、範囲判定をするべきか、あるいはど"
"のようにするべきかについての合意は (まだ) 得られていません。現在の状況の完全"
"な詳細は :pep:`275` を参照してください。"

#: ../../faq/design.rst:313
msgid ""
"For cases where you need to choose from a very large number of "
"possibilities, you can create a dictionary mapping case values to functions "
"to call.  For example::"
msgstr ""
"非常に大きな数の選択肢から選ぶとき、値を呼び出す関数に対応づける辞書を作れま"
"す。例えば::"

#: ../../faq/design.rst:327
msgid ""
"For calling methods on objects, you can simplify yet further by using the :"
"func:`getattr` built-in to retrieve methods with a particular name::"
msgstr ""
"オブジェクトのメソッドを呼び出すには、さらに単純に :func:`getattr` 組み込み関"
"数で特定の名前のメソッドを検索できます::"

#: ../../faq/design.rst:339
msgid ""
"It's suggested that you use a prefix for the method names, such as "
"``visit_`` in this example.  Without such a prefix, if values are coming "
"from an untrusted source, an attacker would be able to call any method on "
"your object."
msgstr ""
"メソッドの名前にこの例の ``visit_`` のような接頭辞を使うことを勧めます。この"
"ような接頭辞がないと、信頼できないソースから値が与えられたときに、オブジェク"
"トの任意のメソッドを呼び出す攻撃をされる可能性があります。"

#: ../../faq/design.rst:345
msgid ""
"Can't you emulate threads in the interpreter instead of relying on an OS-"
"specific thread implementation?"
msgstr ""
"OS 特有のスレッド実装に依らずにインタプリタでスレッドをエミュレートすることは"
"できないのですか？"

#: ../../faq/design.rst:347
msgid ""
"Answer 1: Unfortunately, the interpreter pushes at least one C stack frame "
"for each Python stack frame.  Also, extensions can call back into Python at "
"almost random moments.  Therefore, a complete threads implementation "
"requires thread support for C."
msgstr ""
"答 1: 残念なことに、インタプリタは Python のスタックフレームごとに少なくとも"
"一つの C のスタックフレームを push します。同様に、拡張もほとんどランダムなと"
"きに Python にコールバックすることがあります。よって、完全なスレッド実装には "
"C のスレッドサポートが必要です。"

#: ../../faq/design.rst:352
msgid ""
"Answer 2: Fortunately, there is `Stackless Python <https://github.com/"
"stackless-dev/stackless/wiki>`_, which has a completely redesigned "
"interpreter loop that avoids the C stack."
msgstr ""
"答 2: 幸運なことに、`Stackless Python <https://github.com/stackless-dev/"
"stackless/wiki>`_ があります。これは完全に再デザインされたインタープリタで、C"
"のスタックを回避しています。"

#: ../../faq/design.rst:357
msgid "Why can't lambda expressions contain statements?"
msgstr "なぜラムダ式は文を含むことができないのですか?"

#: ../../faq/design.rst:359
msgid ""
"Python lambda expressions cannot contain statements because Python's "
"syntactic framework can't handle statements nested inside expressions.  "
"However, in Python, this is not a serious problem.  Unlike lambda forms in "
"other languages, where they add functionality, Python lambdas are only a "
"shorthand notation if you're too lazy to define a function."
msgstr ""
"Python のラムダ式が文を含むことができないのは、Python の文法的な枠組みが式の"
"中にネストされた文を扱うことができないからです。しかし、Python では、これは深"
"刻な問題ではありません。他の言語のラムダに機能が追加されているのと違い、"
"Python のラムダは単なる、関数を定義するのが面倒すぎる場合のための簡略な記法に"
"過ぎないのです。"

#: ../../faq/design.rst:365
msgid ""
"Functions are already first class objects in Python, and can be declared in "
"a local scope.  Therefore the only advantage of using a lambda instead of a "
"locally-defined function is that you don't need to invent a name for the "
"function -- but that's just a local variable to which the function object "
"(which is exactly the same type of object that a lambda expression yields) "
"is assigned!"
msgstr ""
"関数は既に Python の第一級オブジェクトで、ローカルスコープ内で宣言できます。"
"従って、ローカルで定義された関数ではなくラムダを使う利点は、関数の名前を考え"
"る必要が無いことだけです -- しかし、(ラムダ式が生み出すオブジェクトと厳密に同"
"じ型の) 関数オブジェクトが代入される先はただのローカル変数です！"

#: ../../faq/design.rst:373
msgid "Can Python be compiled to machine code, C or some other language?"
msgstr "Python は C やその他の言語のように機械語にコンパイルできますか？"

#: ../../faq/design.rst:375
msgid ""
"`Cython <http://cython.org/>`_ compiles a modified version of Python with "
"optional annotations into C extensions.  `Nuitka <http://www.nuitka.net/>`_ "
"is an up-and-coming compiler of Python into C++ code, aiming to support the "
"full Python language. For compiling to Java you can consider `VOC <https://"
"voc.readthedocs.io>`_."
msgstr ""
"`Cython <http://cython.org/>`_ は オプションのアノテーション付きのPythonの修"
"正版を C拡張へ変換します。`Nuitka <http://www.nuitka.net/>`_ はPythonをC+"
"+コードへ変換する将来有望なPythonコンパイラで、完全なPython言語をサポートする"
"ことを目的としています。Javaへコンパイラするには、 `VOC <https://voc."
"readthedocs.io>`_ を検討してください。"

#: ../../faq/design.rst:383
msgid "How does Python manage memory?"
msgstr "Python はメモリをどのように管理するのですか？"

#: ../../faq/design.rst:385
msgid ""
"The details of Python memory management depend on the implementation.  The "
"standard implementation of Python, :term:`CPython`, uses reference counting "
"to detect inaccessible objects, and another mechanism to collect reference "
"cycles, periodically executing a cycle detection algorithm which looks for "
"inaccessible cycles and deletes the objects involved. The :mod:`gc` module "
"provides functions to perform a garbage collection, obtain debugging "
"statistics, and tune the collector's parameters."
msgstr ""
"Python のメモリ管理の詳細は実装に依ります。Python の標準の C 実装 :term:"
"`CPython` は参照カウントを使って、アクセスできないオブジェクトを探します。ま"
"た別のメカニズムを使って参照サイクルを集めます。これはサイクル検出アルゴリズ"
"ムを定期的に実行し、アクセスできないサイクルを探し、巻き込まれたオブジェクト"
"を削除します。 :mod:`gc` モジュールの関数で、ガベージコレクションを実行し、デ"
"バッグ統計を取得し、コレクタのパラメタを変更できます。"

#: ../../faq/design.rst:393
msgid ""
"Other implementations (such as `Jython <http://www.jython.org>`_ or `PyPy "
"<http://www.pypy.org>`_), however, can rely on a different mechanism such as "
"a full-blown garbage collector.  This difference can cause some subtle "
"porting problems if your Python code depends on the behavior of the "
"reference counting implementation."
msgstr ""
"ただし、他の実装 (例えば `Jython <http://www.jython.org>`_ や `PyPy <http://"
"www.pypy.org>`_) は本格的 (full-blown) なガベージコレクタのような別のメカニズ"
"ムに依存するかもしれません。あなたの Python コードが参照カウントの実装の振る"
"舞いに依存する場合、この違いが微妙な移植上の問題を引き起こすでしょう。"

#: ../../faq/design.rst:399
msgid ""
"In some Python implementations, the following code (which is fine in "
"CPython) will probably run out of file descriptors::"
msgstr ""
"Python の実装によっては、以下の (CPython では通る) コードはおそらく、ファイル"
"ディスクリプタを使い果たすでしょう::"

#: ../../faq/design.rst:406
msgid ""
"Indeed, using CPython's reference counting and destructor scheme, each new "
"assignment to *f* closes the previous file.  With a traditional GC, however, "
"those file objects will only get collected (and closed) at varying and "
"possibly long intervals."
msgstr ""
"実際、CPython の参照カウントとデストラクタのスキームを使えば *f* への新しい代"
"入ごとにファイルは閉じられます。しかし、伝統的な GC を使うと、これらのファイ"
"ルオブジェクトが回収され (て閉じられる) までに不定な、場合によっては長い、間"
"隔が空くことがあります。"

#: ../../faq/design.rst:411
msgid ""
"If you want to write code that will work with any Python implementation, you "
"should explicitly close the file or use the :keyword:`with` statement; this "
"will work regardless of memory management scheme::"
msgstr ""
"Python の実装に依らずに動くコードを書くには、ファイルを明示的に閉じるか、 :"
"keyword:`with` 文を使ってください。これでメモリ管理のスキームに関係なく動きま"
"す::"

#: ../../faq/design.rst:421
msgid "Why doesn't CPython use a more traditional garbage collection scheme?"
msgstr "CPython はなぜ伝統的なガベージコレクションスキームを使わないのですか？"

#: ../../faq/design.rst:423
msgid ""
"For one thing, this is not a C standard feature and hence it's not portable. "
"(Yes, we know about the Boehm GC library.  It has bits of assembler code for "
"*most* common platforms, not for all of them, and although it is mostly "
"transparent, it isn't completely transparent; patches are required to get "
"Python to work with it.)"
msgstr ""
"まず、それは C の標準的な機能ではないのでポータブルではありません。(確かに "
"Boehm GC ライブラリはあります。しかし、これにはアセンブリコードが含まれ、*ほ"
"とんどの* 有名なプラットフォームに対応していますが全てではありません。また、"
"ほとんど透過的ですが、完全に透過的ではありません。Python を対応させるにはパッ"
"チが必要です。)"

#: ../../faq/design.rst:429
msgid ""
"Traditional GC also becomes a problem when Python is embedded into other "
"applications.  While in a standalone Python it's fine to replace the "
"standard malloc() and free() with versions provided by the GC library, an "
"application embedding Python may want to have its *own* substitute for "
"malloc() and free(), and may not want Python's.  Right now, CPython works "
"with anything that implements malloc() and free() properly."
msgstr ""
"伝統的な GC は Python が他のアプリケーションに組み込まれるときにも問題となり"
"ます。スタンドアロンの Python で動く限りでは、標準の malloc() と free() を "
"GC ライブラリから提供されるものに置き換えても問題ありませんが、Python を実装"
"したアプリケーションは Python のものではない *独自の* 代替品を使おうとするか"
"もしれません。現在のようにすることで、CPython は malloc() と free() が適切に"
"実装されている限りどんなものにも対応させられます。"

#: ../../faq/design.rst:438
msgid "Why isn't all memory freed when CPython exits?"
msgstr ""
"なぜ CPython の終了時にすべてのメモリが解放されるわけではないのですか？"

#: ../../faq/design.rst:440
msgid ""
"Objects referenced from the global namespaces of Python modules are not "
"always deallocated when Python exits.  This may happen if there are circular "
"references.  There are also certain bits of memory that are allocated by the "
"C library that are impossible to free (e.g. a tool like Purify will complain "
"about these).  Python is, however, aggressive about cleaning up memory on "
"exit and does try to destroy every single object."
msgstr ""
"Python モジュールのグローバルな名前空間から参照されるオブジェクトは、Python "
"の終了時にメモリの割り当てを解除されるとは限りません。これは、循環参照がある"
"ときに起こりえます。解放できない C ライブラリ (例えば、Purify のようなツール"
"などが当てはまります) によって割り当てられたいくらかのメモリも含まれます。し"
"かし、Python は終了時にメモリをクリーンアップすることには積極的で、全ての単一"
"のオブジェクトを破棄しようとします。"

#: ../../faq/design.rst:447
msgid ""
"If you want to force Python to delete certain things on deallocation use "
"the :mod:`atexit` module to run a function that will force those deletions."
msgstr ""
"再割り当て時に Python が特定のものを削除するように強制したいときは、 :mod:"
"`atexit` モジュールを使って削除を強制する関数を実行してください。"

#: ../../faq/design.rst:452
msgid "Why are there separate tuple and list data types?"
msgstr "なぜタプルとリストという別のデータ型が用意されているのですか？"

#: ../../faq/design.rst:454
msgid ""
"Lists and tuples, while similar in many respects, are generally used in "
"fundamentally different ways.  Tuples can be thought of as being similar to "
"Pascal records or C structs; they're small collections of related data which "
"may be of different types which are operated on as a group.  For example, a "
"Cartesian coordinate is appropriately represented as a tuple of two or three "
"numbers."
msgstr ""
"リストとタプルは、多くの点で似ていますが、一般には本質的に異なる方法で使われ"
"ます。タプルは、Pascal のレコードや C の構造体と同様なものと考えられます。型"
"が異なっても良い関連するデータの小さな集合で、グループとして演算されます。例"
"えば、デカルト座標は 2 つや 3 つの数のタプルとして適切に表せます。"

#: ../../faq/design.rst:461
msgid ""
"Lists, on the other hand, are more like arrays in other languages.  They "
"tend to hold a varying number of objects all of which have the same type and "
"which are operated on one-by-one.  For example, ``os.listdir('.')`` returns "
"a list of strings representing the files in the current directory.  "
"Functions which operate on this output would generally not break if you "
"added another file or two to the directory."
msgstr ""
"一方、リストは、もっと他の言語の配列に近いものです。全て同じ型の可変数のオブ"
"ジェクトを持ち、それらが一つ一つ演算される傾向にあります。例えば、 ``os."
"listdir('.')`` はカレントディレクトリ内にあるファイルの文字列表現のリストを返"
"します。この出力を演算する関数は一般に、ディレクトリに一つや二つの別のファイ"
"ルを加えても壊れません。"

#: ../../faq/design.rst:468
msgid ""
"Tuples are immutable, meaning that once a tuple has been created, you can't "
"replace any of its elements with a new value.  Lists are mutable, meaning "
"that you can always change a list's elements.  Only immutable elements can "
"be used as dictionary keys, and hence only tuples and not lists can be used "
"as keys."
msgstr ""
"タプルはイミュータブルなので、一度タプルが生成されたら、そのどの要素も新しい"
"値に置き換えられません。リストはミュータブルなので、リストの要素はいつでも変"
"更できます。イミュータブルな要素だけが辞書のキーとして使えるので、リストでは"
"なくタプルだけがキーとして使えます。"

#: ../../faq/design.rst:475
msgid "How are lists implemented in CPython?"
msgstr "CPythonでリストはどのように実装されているのですか？"

#: ../../faq/design.rst:477
msgid ""
"CPython's lists are really variable-length arrays, not Lisp-style linked "
"lists. The implementation uses a contiguous array of references to other "
"objects, and keeps a pointer to this array and the array's length in a list "
"head structure."
msgstr ""
"CPythonのリストは実際に変数分の長さの配列で、Lispスタイルの連結リストではあり"
"ません。この実装は他のオブジェクトへの参照の連続した配列を使用していて、この"
"配列へのポインタおよび配列長はリストの先頭の構造体に保存されています。"

#: ../../faq/design.rst:481
msgid ""
"This makes indexing a list ``a[i]`` an operation whose cost is independent "
"of the size of the list or the value of the index."
msgstr ""
"これにより、リストのインデクシング ``a[i]`` は、リストの大きさやインデクスの"
"値に依存しないコストで演算できます。"

#: ../../faq/design.rst:484
msgid ""
"When items are appended or inserted, the array of references is resized.  "
"Some cleverness is applied to improve the performance of appending items "
"repeatedly; when the array must be grown, some extra space is allocated so "
"the next few times don't require an actual resize."
msgstr ""
"要素が追加または挿入されるとき、この参照の配列は大きさが変更されます。要素追"
"加の繰り返しのパフォーマンスを上げるために、少し工夫されています。配列が大き"
"くなるとき、次の何回かは実際に大きさを変更する必要がないように、いくらかの追"
"加の領域が割り当てられます。"

#: ../../faq/design.rst:491
msgid "How are dictionaries implemented in CPython?"
msgstr "CPythonで辞書はどのように実装されていますか？"

#: ../../faq/design.rst:493
msgid ""
"CPython's dictionaries are implemented as resizable hash tables.  Compared "
"to B-trees, this gives better performance for lookup (the most common "
"operation by far) under most circumstances, and the implementation is "
"simpler."
msgstr ""
"CPython の辞書は大きさを変更できるハッシュテーブルとして実装されています。B "
"木と比べて、ほとんどの条件下で (特に一般的な演算である) 探索のパフォーマンス"
"が良いですし、実装も単純です。"

#: ../../faq/design.rst:497
msgid ""
"Dictionaries work by computing a hash code for each key stored in the "
"dictionary using the :func:`hash` built-in function.  The hash code varies "
"widely depending on the key and a per-process seed; for example, \"Python\" "
"could hash to -539294296 while \"python\", a string that differs by a single "
"bit, could hash to 1142331976.  The hash code is then used to calculate a "
"location in an internal array where the value will be stored.  Assuming that "
"you're storing keys that all have different hash values, this means that "
"dictionaries take constant time -- O(1), in Big-O notation -- to retrieve a "
"key."
msgstr ""
"辞書は、 辞書に保存されているそれぞれのキーに対応するハッシュコードを:func:"
"`hash` ビルトイン関数で計算することで機能します。このハッシュコードはキーやプ"
"ロセスごとのシードによって大きく変化します。例えば、\"Python\" のハッシュ値"
"は -539294296 ですが、ビットが一つ違うだけの文字列 \"python\" のハッシュ値は "
"1142331976 です。そしてこのハッシュコードは、値が保存される内部配列での位置を"
"計算するために使われます。保存しているキーのハッシュ値が全て異なるとすれば、"
"一定の時間 − big O-記法ではO(1) − でキーを検索できることになります。"

#: ../../faq/design.rst:508
msgid "Why must dictionary keys be immutable?"
msgstr "なぜ辞書のキーはイミュータブルでなくてはならないのですか？"

#: ../../faq/design.rst:510
msgid ""
"The hash table implementation of dictionaries uses a hash value calculated "
"from the key value to find the key.  If the key were a mutable object, its "
"value could change, and thus its hash could also change.  But since whoever "
"changes the key object can't tell that it was being used as a dictionary "
"key, it can't move the entry around in the dictionary.  Then, when you try "
"to look up the same object in the dictionary it won't be found because its "
"hash value is different. If you tried to look up the old value it wouldn't "
"be found either, because the value of the object found in that hash bin "
"would be different."
msgstr ""
"辞書のハッシュテーブルの実装は、キーを見つけるために、キー値から計算された"
"ハッシュ値を使います。もしキーがミュータブルなオブジェクトだったら、その値は"
"変えられ、それによりハッシュ値も変わってしまいます。しかし、キーオブジェクト"
"を変更したのが何者であれ、値が辞書のキーとして使われていたと気付けないので、"
"辞書の中のエントリを適切な場所に動かせません。そして、同じオブジェクトを探そ"
"うとしても、ハッシュ値が違うため見つかりません。古い値を探そうとしても、その"
"ハッシュバイナリから見つかるオブジェクトの値は異なるでしょうから、これも見つ"
"かりません。"

#: ../../faq/design.rst:519
msgid ""
"If you want a dictionary indexed with a list, simply convert the list to a "
"tuple first; the function ``tuple(L)`` creates a tuple with the same entries "
"as the list ``L``.  Tuples are immutable and can therefore be used as "
"dictionary keys."
msgstr ""
"リストでインデクシングされた辞書が必要なら、まず単純にリストをタプルに変換し"
"てください。関数 ``tuple(L)`` は、リスト ``L`` と同じエントリのタプルを生成し"
"ます。タプルはイミュータブルなので、辞書のキーとして使えます。"

#: ../../faq/design.rst:523
msgid "Some unacceptable solutions that have been proposed:"
msgstr "いくつかの受け入れられなかった提案:"

#: ../../faq/design.rst:525
msgid ""
"Hash lists by their address (object ID).  This doesn't work because if you "
"construct a new list with the same value it won't be found; e.g.::"
msgstr ""
"アドレス (オブジェクト ID) のハッシュリスト。これは、同じ値の新しいリストを"
"作っても見つからないので駄目です。例えば::"

#: ../../faq/design.rst:531
msgid ""
"would raise a :exc:`KeyError` exception because the id of the ``[1, 2]`` "
"used in the second line differs from that in the first line.  In other "
"words, dictionary keys should be compared using ``==``, not using :keyword:"
"`is`."
msgstr ""
"``[1, 2]`` の2行目のidは1行目のそれと異なってしまうために :exc:`KeyError` 例"
"外を送出するでしょう。言い換えれば、辞書のキーは ``==`` を使って比較されるべ"
"きであり、 :keyword:`is` ではないということです。"

#: ../../faq/design.rst:535
msgid ""
"Make a copy when using a list as a key.  This doesn't work because the list, "
"being a mutable object, could contain a reference to itself, and then the "
"copying code would run into an infinite loop."
msgstr ""
"リストをキーとして使うときにコピーを作る。リストはミュータブルなので、自分自"
"身への参照を含むことができ、コードをコピーするときに無限ループにハマる可能性"
"があるので、これは駄目です。"

#: ../../faq/design.rst:539
msgid ""
"Allow lists as keys but tell the user not to modify them.  This would allow "
"a class of hard-to-track bugs in programs when you forgot or modified a list "
"by accident. It also invalidates an important invariant of dictionaries: "
"every value in ``d.keys()`` is usable as a key of the dictionary."
msgstr ""
"リストをキーとして使うことを認めるが、ユーザにそれを変更させないように伝え"
"る。もしユーザが忘れたり、偶然にリストが変更されてしまったりしたら、追跡困難"
"なバグの可能性を生じてしまいます。またこれは、 ``d.keys()`` のすべての値は辞"
"書のキーとして使えるという、辞書の重要な不変性も潰してしまいます。"

#: ../../faq/design.rst:544
msgid ""
"Mark lists as read-only once they are used as a dictionary key.  The problem "
"is that it's not just the top-level object that could change its value; you "
"could use a tuple containing a list as a key.  Entering anything as a key "
"into a dictionary would require marking all objects reachable from there as "
"read-only -- and again, self-referential objects could cause an infinite "
"loop."
msgstr ""
"リストが一旦辞書のキーとして使われたら、読み出し専用のマークを付ける。問題"
"は、値を変えられるのはトップレベルオブジェクトだけではないことです。リストを"
"含むタプルもキーとして使えます。全てを辞書のキーとして導入すると、そこから到"
"達可能な全てのオブジェクトに読み出し専用のマークを付ける必要があります -- そ"
"して再び、自己参照オブジェクトが無限ループを引き起こします。"

#: ../../faq/design.rst:550
msgid ""
"There is a trick to get around this if you need to, but use it at your own "
"risk: You can wrap a mutable structure inside a class instance which has "
"both a :meth:`__eq__` and a :meth:`__hash__` method.  You must then make "
"sure that the hash value for all such wrapper objects that reside in a "
"dictionary (or other hash based structure), remain fixed while the object is "
"in the dictionary (or other structure). ::"
msgstr ""
"必要ならばこれを回避する方法がありますが、自己責任のもとで行ってください。"
"ミュータブルな構造を、 :meth:`__eq__` と :meth:`__hash__` メソッドの両方を持"
"つクラスインスタンスに含めることができます。その時、辞書 (またはハッシュに基"
"づく別の構造体) に属するような全てのラッパーオブジェクトのハッシュ値が、その"
"オブジェクトが辞書 (その他の構造体) 中にある間固定され続けることを確実にして"
"ください。 ::"

#: ../../faq/design.rst:574
msgid ""
"Note that the hash computation is complicated by the possibility that some "
"members of the list may be unhashable and also by the possibility of "
"arithmetic overflow."
msgstr ""
"なお、リストのメンバーの中にハッシュ化できないものがある可能性や、算術オー"
"バーフローの可能性から、ハッシュ計算は複雑になります。"

#: ../../faq/design.rst:578
msgid ""
"Furthermore it must always be the case that if ``o1 == o2`` (ie ``o1."
"__eq__(o2) is True``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == "
"o2.__hash__()``), regardless of whether the object is in a dictionary or "
"not.  If you fail to meet these restrictions dictionaries and other hash "
"based structures will misbehave."
msgstr ""
"さらに、そのオブジェクトが辞書に含まれるか否かにかかわらず、 ``o1 == o2`` (す"
"なわち ``o1.__eq__(o2) is True``) ならばいつでも ``hash(o1) == hash(o2)`` (す"
"なわち ``o1.__hash__() == o2.__hash__()``) でなくてはなりません。その制限に適"
"合できなければ、辞書やその他のハッシュに基づく構造体は間違いを起こします。"

#: ../../faq/design.rst:583
msgid ""
"In the case of ListWrapper, whenever the wrapper object is in a dictionary "
"the wrapped list must not change to avoid anomalies.  Don't do this unless "
"you are prepared to think hard about the requirements and the consequences "
"of not meeting them correctly.  Consider yourself warned."
msgstr ""
"この ListWrapper の例では、異常を避けるため、ラッパオブジェクトが辞書内にある"
"限りラップされたリストが変更されてはなりません。この条件と満たせなかった時の"
"結果について知恵を絞る覚悟がない限り、これをしてはいけません。よく考えてくだ"
"さい。"

#: ../../faq/design.rst:590
msgid "Why doesn't list.sort() return the sorted list?"
msgstr "なぜ list.sort() はソートされたリストを返さないのですか？"

#: ../../faq/design.rst:592
msgid ""
"In situations where performance matters, making a copy of the list just to "
"sort it would be wasteful. Therefore, :meth:`list.sort` sorts the list in "
"place. In order to remind you of that fact, it does not return the sorted "
"list.  This way, you won't be fooled into accidentally overwriting a list "
"when you need a sorted copy but also need to keep the unsorted version "
"around."
msgstr ""
"パフォーマンスが問題となる状況では、ソートするためだけにリストのコピーを作る"
"のは無駄が多いです。そこで、 :meth:`list.sort` はインプレースにリストをソート"
"します。このことを忘れないため、この関数はソートされたリストを返しません。こ"
"うすることで、ソートされたコピーが必要で、ソートされていないものも残しておき"
"たいときに、うっかり上書きしてしまうようなことがなくなります。"

#: ../../faq/design.rst:598
msgid ""
"If you want to return a new list, use the built-in :func:`sorted` function "
"instead.  This function creates a new list from a provided iterable, sorts "
"it and returns it.  For example, here's how to iterate over the keys of a "
"dictionary in sorted order::"
msgstr ""
"新しいリストを返したいなら、代わりに組み込みの :func:`sorted` 関数を使ってく"
"ださい。この関数は、与えられたイテレート可能オブジェクトから新しいリストを生"
"成し、ソートして返します。例えば、辞書のキーをソートされた順序でイテレートす"
"る方法は::"

#: ../../faq/design.rst:608
msgid "How do you specify and enforce an interface spec in Python?"
msgstr "Python ではどのようにインタフェース仕様を特定し適用するのですか？"

#: ../../faq/design.rst:610
msgid ""
"An interface specification for a module as provided by languages such as C++ "
"and Java describes the prototypes for the methods and functions of the "
"module.  Many feel that compile-time enforcement of interface specifications "
"helps in the construction of large programs."
msgstr ""
"C++ や Java のような言語が提供するような、モジュールに対するインタフェース仕"
"様の特定は、モジュールのメソッドや関数の原型を表現します。インタフェースの特"
"定がコンパイル時に適用されることが、大きなプログラムの構成に役立つと、広く感"
"じられています。"

#: ../../faq/design.rst:615
msgid ""
"Python 2.6 adds an :mod:`abc` module that lets you define Abstract Base "
"Classes (ABCs).  You can then use :func:`isinstance` and :func:`issubclass` "
"to check whether an instance or a class implements a particular ABC.  The :"
"mod:`collections.abc` module defines a set of useful ABCs such as :class:"
"`~collections.abc.Iterable`, :class:`~collections.abc.Container`, and :class:"
"`~collections.abc.MutableMapping`."
msgstr ""
"Python 2.6 で、抽象基底クラス (Abstract Base Class, ABC) が定義できるようにな"
"る :mod:`abc` モジュールが追加されました。なので :func:`isinstance` と :func:"
"`issubclass` を使って、インスタンスやクラスが、ある ABC を実装しているかどう"
"かチェックできます。:mod:`collections.abc` モジュールでは、 :class:"
"`~collections.abc.Iterable` 、 :class:`~collections.abc.Container` 、 :class:"
"`~collections.abc.MutableMapping` などの便利な ABC が定義されています。"

#: ../../faq/design.rst:622
msgid ""
"For Python, many of the advantages of interface specifications can be "
"obtained by an appropriate test discipline for components.  There is also a "
"tool, PyChecker, which can be used to find problems due to subclassing."
msgstr ""
"Python では、コンポーネントの適切なテスト規律によって、インタフェース仕様の多"
"くの強みを活かせます。サブクラス化による問題を見つけるために使えるツール "
"PyChecker もあります。"

#: ../../faq/design.rst:626
msgid ""
"A good test suite for a module can both provide a regression test and serve "
"as a module interface specification and a set of examples.  Many Python "
"modules can be run as a script to provide a simple \"self test.\"  Even "
"modules which use complex external interfaces can often be tested in "
"isolation using trivial \"stub\" emulations of the external interface.  The :"
"mod:`doctest` and :mod:`unittest` modules or third-party test frameworks can "
"be used to construct exhaustive test suites that exercise every line of code "
"in a module."
msgstr ""
"モジュールのための適切なテストスイートは、回帰テストを提供し、モジュールのイ"
"ンタフェース仕様や用例集としても役立ちます。多くの Python モジュールは、簡単"
"な「自己テスト」を提供するスクリプトとして実行できます。複雑な外部インタ"
"フェースを使うモジュールさえ、外部インタフェースの細かい「スタブ」エミュレー"
"ションで単独にテストできることが多いです。 :mod:`doctest` や :mod:`unittest` "
"モジュール、あるいはサードパーティのテストフレームワークで、モジュールのコー"
"ドの全ての行に及ぶ徹底的なテストスイートを構成できます。"

#: ../../faq/design.rst:634
msgid ""
"An appropriate testing discipline can help build large complex applications "
"in Python as well as having interface specifications would.  In fact, it can "
"be better because an interface specification cannot test certain properties "
"of a program.  For example, the :meth:`append` method is expected to add new "
"elements to the end of some internal list; an interface specification cannot "
"test that your :meth:`append` implementation will actually do this "
"correctly, but it's trivial to check this property in a test suite."
msgstr ""
"Python で大きくて複雑なアプリケーションを構築するとき、インタフェース仕様と同"
"様に、適切なテスト規律も役立ちます。実際には、インタフェース仕様ではテストで"
"きないプログラムの属性もあるので、それ以上にもなりえます。例えば、 :meth:"
"`append` メソッドは新しい要素をある内部リストの終わりに加えます。インタフェー"
"ス仕様ではこの :meth:`append` の実装が実際にこれを行うかをテストできません"
"が、テストスイートならこの機能を簡単に確かめられます。"

#: ../../faq/design.rst:642
msgid ""
"Writing test suites is very helpful, and you might want to design your code "
"with an eye to making it easily tested.  One increasingly popular technique, "
"test-directed development, calls for writing parts of the test suite first, "
"before you write any of the actual code.  Of course Python allows you to be "
"sloppy and not write test cases at all."
msgstr ""
"テストスイートを書くことはとても役に立ちますし、テストのしやすさという視点で"
"コードを設計することにもつながります。テスト指向開発は、人気を増しつつある技"
"法で、実際のコードを書き始める前に、最初からテストスイートの部品を書くことを"
"求めます。もちろん、 Python で粗雑にテストケースを全く書かないこともできま"
"す。"

#: ../../faq/design.rst:650
msgid "Why is there no goto?"
msgstr "なぜ goto が無いのですか？"

#: ../../faq/design.rst:652
msgid ""
"You can use exceptions to provide a \"structured goto\" that even works "
"across function calls.  Many feel that exceptions can conveniently emulate "
"all reasonable uses of the \"go\" or \"goto\" constructs of C, Fortran, and "
"other languages.  For example::"
msgstr ""
"関数の呼び出しをまたいでも動作する \"構造化された goto\" をまかなうものとして"
"例外を使えます。C、Fortran、その他の言語での \"go\" あるいは \"goto\" 構造の"
"適切な用途は全て、例外で同じようなことををすれば便利であると、広く感じられて"
"います。例えば::"

#: ../../faq/design.rst:667
msgid ""
"This doesn't allow you to jump into the middle of a loop, but that's usually "
"considered an abuse of goto anyway.  Use sparingly."
msgstr ""
"例外ではループ内へ跳ぶことはできませんが、どちらにしてもそれは goto の乱用と"
"見なされるものです。使うのは控えてください。"

#: ../../faq/design.rst:672
msgid "Why can't raw strings (r-strings) end with a backslash?"
msgstr ""
"なぜ raw 文字列 (r-strings) はバックスラッシュで終わってはいけないのですか？"

#: ../../faq/design.rst:674
msgid ""
"More precisely, they can't end with an odd number of backslashes: the "
"unpaired backslash at the end escapes the closing quote character, leaving "
"an unterminated string."
msgstr ""
"正確には、奇数個のバックスラッシュで終わってはいけません。終わりの対になって"
"いないバックスラッシュは、閉じ引用文字をエスケープし、終っていない文字列を残"
"してしまいます。"

#: ../../faq/design.rst:678
msgid ""
"Raw strings were designed to ease creating input for processors (chiefly "
"regular expression engines) that want to do their own backslash escape "
"processing. Such processors consider an unmatched trailing backslash to be "
"an error anyway, so raw strings disallow that.  In return, they allow you to "
"pass on the string quote character by escaping it with a backslash.  These "
"rules work well when r-strings are used for their intended purpose."
msgstr ""
"raw 文字列は、独自にバックスラッシュの処理をしようとするプロセッサ (主に正規"
"表現エンジン) への入力を生成しやすいように設計されたものです。このようなプロ"
"セッサは、終端の対になっていないバックスラッシュを結局エラーとみなすので、"
"raw 文字列はそれを認めません。その代わりに、バックスラッシュでエスケープする"
"ことで、引用文字を文字列として渡すことができます。r-string が意図された目的に"
"使われるときに、この規則が役に立つのです。"

#: ../../faq/design.rst:685
msgid ""
"If you're trying to build Windows pathnames, note that all Windows system "
"calls accept forward slashes too::"
msgstr ""
"Windows のパス名を構築するときには、Windows のシステムコールは普通のスラッ"
"シュも受け付けることを憶えておいてください::"

#: ../../faq/design.rst:690
msgid ""
"If you're trying to build a pathname for a DOS command, try e.g. one of ::"
msgstr ""
"DOS コマンドのパス名を構築するときには、例えばこの中のどれかを試してくださ"
"い::"

#: ../../faq/design.rst:698
msgid "Why doesn't Python have a \"with\" statement for attribute assignments?"
msgstr "属性の代入に \"with\" 文が使えないのはなぜですか？"

#: ../../faq/design.rst:700
msgid ""
"Python has a 'with' statement that wraps the execution of a block, calling "
"code on the entrance and exit from the block.  Some language have a "
"construct that looks like this::"
msgstr ""
"Python には、ブロックの実行を包む 'with' 文があり、ブロックに入るときとブロッ"
"クから出るときに、コードを呼び出します。以下のような構造を持つ言語がありま"
"す::"

#: ../../faq/design.rst:708
msgid "In Python, such a construct would be ambiguous."
msgstr "Python では、このような構造は曖昧になるでしょう。"

#: ../../faq/design.rst:710
msgid ""
"Other languages, such as Object Pascal, Delphi, and C++, use static types, "
"so it's possible to know, in an unambiguous way, what member is being "
"assigned to. This is the main point of static typing -- the compiler "
"*always* knows the scope of every variable at compile time."
msgstr ""
"Object Pascal、Delphi、C++のような他の言語では、静的な型を使うので、曖昧な方"
"法でも、どのメンバに代入されているのか分かります。これが静的型付けの要点です "
"-- コンパイラは *いつでも* コンパイル時にすべての変数のスコープを知るのです。"

#: ../../faq/design.rst:715
msgid ""
"Python uses dynamic types. It is impossible to know in advance which "
"attribute will be referenced at runtime. Member attributes may be added or "
"removed from objects on the fly. This makes it impossible to know, from a "
"simple reading, what attribute is being referenced: a local one, a global "
"one, or a member attribute?"
msgstr ""
"Python は動的な型を使います。実行時にどの属性が参照されるか事前に分かりませ"
"ん。動作中にメンバ属性が追加あるいは除去されるかもしれません。これでは、単純"
"に読むだけではどのアトリビュートが参照されているか分かりません。ローカルなの"
"か、グローバルなのか、メンバ属性なのか？"

#: ../../faq/design.rst:721
msgid "For instance, take the following incomplete snippet::"
msgstr "例えば、以下の不完全なコード片を考えましょう::"

#: ../../faq/design.rst:727
msgid ""
"The snippet assumes that \"a\" must have a member attribute called \"x\".  "
"However, there is nothing in Python that tells the interpreter this. What "
"should happen if \"a\" is, let us say, an integer?  If there is a global "
"variable named \"x\", will it be used inside the with block?  As you see, "
"the dynamic nature of Python makes such choices much harder."
msgstr ""
"このコード片では、\"a\" は \"x\" というメンバ属性を持っていると仮定されていま"
"す。しかし、Python ではインタプリタにはこの仮定を伝えられる仕組みはありませ"
"ん。 \"a\" が、例えば整数だったら、どうなってしまうでしょうか。 \"x\" という"
"名前のグローバル変数があったら、それが with ブロックの中で使われるのでしょう"
"か。この通り、Python の動的な特質から、このような選択はとても難しい物になって"
"います。"

#: ../../faq/design.rst:733
msgid ""
"The primary benefit of \"with\" and similar language features (reduction of "
"code volume) can, however, easily be achieved in Python by assignment.  "
"Instead of::"
msgstr ""
"しかし、\"with\" やそれに類する言語の機能の一番の利点 (コード量の削減) は、 "
"Python では代入により簡単に手に入れられます::"

#: ../../faq/design.rst:740
msgid "write this::"
msgstr "こう書いてください::"

#: ../../faq/design.rst:747
msgid ""
"This also has the side-effect of increasing execution speed because name "
"bindings are resolved at run-time in Python, and the second version only "
"needs to perform the resolution once."
msgstr ""
"Python では実行時に名前束縛が解決され、後者はその解決が一度で済むため、これに"
"は実行速度をあげる副作用もあります。"

#: ../../faq/design.rst:753
msgid "Why are colons required for the if/while/def/class statements?"
msgstr "if/while/def/class 文にコロンが必要なのはなぜですか？"

#: ../../faq/design.rst:755
msgid ""
"The colon is required primarily to enhance readability (one of the results "
"of the experimental ABC language).  Consider this::"
msgstr ""
"主に可読性を高めるため (実験的な ABC 言語の結果の一つ) に、コロンが必要です::"

#: ../../faq/design.rst:761
msgid "versus ::"
msgstr "と::"

#: ../../faq/design.rst:766
msgid ""
"Notice how the second one is slightly easier to read.  Notice further how a "
"colon sets off the example in this FAQ answer; it's a standard usage in "
"English."
msgstr ""
"を考えれば、後者のほうが少し読みやすいでしょう。さらに言えば、この FAQ の解答"
"例は次のようになるでしょう。これは、英語の標準的な用法です。"

#: ../../faq/design.rst:769
msgid ""
"Another minor reason is that the colon makes it easier for editors with "
"syntax highlighting; they can look for colons to decide when indentation "
"needs to be increased instead of having to do a more elaborate parsing of "
"the program text."
msgstr ""
"他の小さな理由は、コロンによってエディタがシンタックスハイライトをしやすくな"
"ることです。プログラムテキストの手の込んだ解析をしなくても、コロンを探せばい"
"つインデントを増やすべきかを決められます。"

#: ../../faq/design.rst:775
msgid "Why does Python allow commas at the end of lists and tuples?"
msgstr "なぜ Python ではリストやタプルの最後にカンマがあっても良いのですか？"

#: ../../faq/design.rst:777
msgid ""
"Python lets you add a trailing comma at the end of lists, tuples, and "
"dictionaries::"
msgstr ""
"Python では、リスト、タプル、辞書の最後の要素の後端にカンマをつけても良いこと"
"になっています::"

#: ../../faq/design.rst:788
msgid "There are several reasons to allow this."
msgstr "これを許すのには、いくつかの理由があります。"

#: ../../faq/design.rst:790
msgid ""
"When you have a literal value for a list, tuple, or dictionary spread across "
"multiple lines, it's easier to add more elements because you don't have to "
"remember to add a comma to the previous line.  The lines can also be "
"reordered without creating a syntax error."
msgstr ""
"リストやタプルや辞書のリテラルが複数行に渡っているときに、前の行にカンマを追"
"加するのを覚えておく必要が無いため、要素を追加するのが楽になります。また、文"
"法エラーを起こすこと無く、行の並べ替えを行うことができます。"

#: ../../faq/design.rst:795
msgid ""
"Accidentally omitting the comma can lead to errors that are hard to "
"diagnose. For example::"
msgstr ""
"間違えてカンマを落としてしまうと、診断しづらいエラーにつながります。例えば::"

#: ../../faq/design.rst:805
msgid ""
"This list looks like it has four elements, but it actually contains three: "
"\"fee\", \"fiefoo\" and \"fum\".  Always adding the comma avoids this source "
"of error."
msgstr ""
"このリストには4つの要素があるように見えますが、実際には3つしかありません。\n"
"\"fee\"、\"fiefoo\"、\"fum\" です。\n"
"常にカンマを付けるようにすれば、この種のエラーが避けられます。"

#: ../../faq/design.rst:808
msgid ""
"Allowing the trailing comma may also make programmatic code generation "
"easier."
msgstr ""
"後端にカンマをつけても良いことにすれば、プログラムによるコード生成も簡単にな"
"ります。"