design.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2025, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
# Translators:
# tomo, 2021
# mollinaca, 2021
# Mikami Akiko, 2021
# 菊池 健志, 2023
# Arihiro TAKASE, 2023
# TENMYO Masakazu, 2024
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.13\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2025-04-18 14:18+0000\n"
"PO-Revision-Date: 2021-06-28 00:52+0000\n"
"Last-Translator: TENMYO Masakazu, 2024\n"
"Language-Team: Japanese (https://app.transifex.com/python-doc/teams/5390/"
"ja/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: ja\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:21
msgid ""
"if (x <= y)\n"
"        x++;\n"
"        y--;\n"
"z++;"
msgstr ""

#: ../../faq/design.rst:26
msgid ""
"Only the ``x++`` statement is executed if the condition is true, but the "
"indentation leads many to believe otherwise.  Even experienced C programmers "
"will sometimes stare at it a long time wondering as to why ``y`` is being "
"decremented even for ``x > y``."
msgstr ""
"条件式が真のとき、 ``x++`` 行のみが実行されます。しかしインデントによって、多"
"くの人が別のことを考えてしまいます。経験豊富なCプログラマでさえ、 ``x > y`` "
"なのに ``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. "
"After becoming used to reading and writing code using a particular style, it "
"is normal to feel somewhat uneasy when reading (or being required to write) "
"in a different one."
msgstr ""
"Python は開始/終了の括弧がないので、コーディングスタイルの争いに余り影響され"
"ません。C言語では中括弧の置き方についてさまざまな流儀があります。特定のスタイ"
"ルを使ってコードを読み書きするのに慣れたあと、別のスタイルでコードを読んだり"
"(あるいは書く必要に迫られたり)するときに、何となく心配になるのはよくあること"
"です。"

#: ../../faq/design.rst:38
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:48
msgid "Why am I getting strange results with simple arithmetic operations?"
msgstr "なぜ単純な算術演算が奇妙な結果になるのですか？"

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

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

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

#: ../../faq/design.rst:58
msgid ""
">>> 1.2 - 1.0\n"
"0.19999999999999996"
msgstr ""

#: ../../faq/design.rst:61
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:65
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:72
msgid ""
"Many numbers that can be written easily in decimal notation cannot be "
"expressed exactly in binary floating point.  For example, after::"
msgstr ""

#: ../../faq/design.rst:75
msgid ">>> x = 1.2"
msgstr ""

#: ../../faq/design.rst:77
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 "1.0011001100110011001100110011001100110011001100110011 (binary)"
msgstr ""

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

#: ../../faq/design.rst:85
msgid "1.1999999999999999555910790149937383830547332763671875 (decimal)"
msgstr ""

#: ../../faq/design.rst:87
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:90
msgid ""
"For a fuller explanation, please see the :ref:`floating-point arithmetic "
"<tut-fp-issues>` chapter in the Python tutorial."
msgstr ""

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

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

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

#: ../../faq/design.rst:114
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:117
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:127
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:`~object.__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:`~object.__init__` メソッドに便利ですし、派生クラスのメソッドが、"
"基底クラスにある同じ名前のメソッドを拡張するために、基底クラスのメソッドをど"
"うにかして呼び出したい時にも便利です。"

#: ../../faq/design.rst:136
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:154
msgid "Why can't I use an assignment in an expression?"
msgstr "式中で代入ができないのはなぜですか？"

#: ../../faq/design.rst:156
msgid "Starting in Python 3.8, you can!"
msgstr "Python 3.8 以降ならできるよ!"

#: ../../faq/design.rst:158
msgid ""
"Assignment expressions using the walrus operator ``:=`` assign a variable in "
"an expression::"
msgstr "セイウチ演算子 ``:=`` を使った代入式は、式の中で変数に代入します::"

#: ../../faq/design.rst:161
msgid ""
"while chunk := fp.read(200):\n"
"   print(chunk)"
msgstr ""

#: ../../faq/design.rst:164
msgid "See :pep:`572` for more information."
msgstr "より詳しくは :pep:`572` を参照してください。"

#: ../../faq/design.rst:169
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:171
msgid "As Guido said:"
msgstr "Guidoいわく："

#: ../../faq/design.rst:173
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:180
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:189
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:193
msgid "Why is join() a string method instead of a list or tuple method?"
msgstr ""
"join() がリストやタプルのメソッドではなく文字列のメソッドなのはなぜですか？"

#: ../../faq/design.rst:195
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:201
msgid "\", \".join(['1', '2', '4', '8', '16'])"
msgstr ""

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

#: ../../faq/design.rst:205
msgid "\"1, 2, 4, 8, 16\""
msgstr ""

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

#: ../../faq/design.rst:209
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:215
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:220
msgid "\"1, 2, 4, 8, 16\".split(\", \")"
msgstr ""

#: ../../faq/design.rst:222
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:225
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:233
msgid "How fast are exceptions?"
msgstr "例外はどれくらい速いのですか？"

#: ../../faq/design.rst:235
msgid ""
"A :keyword:`try`/:keyword:`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 ""
":keyword:`try`/:keyword:`except` ブロックは例外が送出されなければ極端に効率的"
"です。実際に例外を捕捉するのは高価です。Python 2.0 より前のバージョンでは、こ"
"のイディオムを使うのが一般的でした::"

#: ../../faq/design.rst:240
msgid ""
"try:\n"
"    value = mydict[key]\n"
"except KeyError:\n"
"    mydict[key] = getvalue(key)\n"
"    value = mydict[key]"
msgstr ""

#: ../../faq/design.rst:246
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:249
msgid ""
"if key in mydict:\n"
"    value = mydict[key]\n"
"else:\n"
"    value = mydict[key] = getvalue(key)"
msgstr ""

#: ../../faq/design.rst:254
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:260
msgid "Why isn't there a switch or case statement in Python?"
msgstr "Python に switch や case 文がないのはなぜですか？"

#: ../../faq/design.rst:262
msgid ""
"In general, structured switch statements execute one block of code when an "
"expression has a particular value or set of values. Since Python 3.10 one "
"can easily match literal values, or constants within a namespace, with a "
"``match ... case`` statement. An older alternative is a sequence of ``if... "
"elif... elif... else``."
msgstr ""
"一般的に、構造化された switch 文は、式が特定の値または値の集合を持つとき、１"
"つのコードブロックを実行します。 Python 3.10 以降では、リテラル値や名前空間内"
"の定数を、 ``match ... case`` 文で簡単にマッチさせることができます。より古い"
"手段は一連の ``if... elif... elif... else`` です。"

#: ../../faq/design.rst:268
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:272
msgid ""
"functions = {'a': function_1,\n"
"             'b': function_2,\n"
"             'c': self.method_1}\n"
"\n"
"func = functions[value]\n"
"func()"
msgstr ""

#: ../../faq/design.rst:279
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:282
msgid ""
"class MyVisitor:\n"
"    def visit_a(self):\n"
"        ...\n"
"\n"
"    def dispatch(self, value):\n"
"        method_name = 'visit_' + str(value)\n"
"        method = getattr(self, method_name)\n"
"        method()"
msgstr ""

#: ../../faq/design.rst:291
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:295
msgid ""
"Imitating switch with fallthrough, as with C's switch-case-default, is "
"possible, much harder, and less needed."
msgstr ""
"C の switch-case-default のような、フォールスルーのある switch を模倣すること"
"もできますが、はるかに難しいうえに必要性も少ないでしょう。"

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

#: ../../faq/design.rst:302
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:307
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:312
msgid "Why can't lambda expressions contain statements?"
msgstr "なぜラムダ式は文を含むことができないのですか?"

#: ../../faq/design.rst:314
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:320
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:328
msgid "Can Python be compiled to machine code, C or some other language?"
msgstr "Python は C やその他の言語のように機械語にコンパイルできますか？"

#: ../../faq/design.rst:330
msgid ""
"`Cython <https://cython.org/>`_ compiles a modified version of Python with "
"optional annotations into C extensions.  `Nuitka <https://nuitka.net/>`_ is "
"an up-and-coming compiler of Python into C++ code, aiming to support the "
"full Python language."
msgstr ""

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

#: ../../faq/design.rst:339
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:347
msgid ""
"Other implementations (such as `Jython <https://www.jython.org>`_ or `PyPy "
"<https://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 ""

#: ../../faq/design.rst:353
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:356
msgid ""
"for file in very_long_list_of_files:\n"
"    f = open(file)\n"
"    c = f.read(1)"
msgstr ""

#: ../../faq/design.rst:360
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:365
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:369
msgid ""
"for file in very_long_list_of_files:\n"
"    with open(file) as f:\n"
"        c = f.read(1)"
msgstr ""

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

#: ../../faq/design.rst:377
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:383
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:392
msgid "Why isn't all memory freed when CPython exits?"
msgstr ""
"なぜ CPython の終了時にすべてのメモリが解放されるわけではないのですか？"

#: ../../faq/design.rst:394
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:401
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:406
msgid "Why are there separate tuple and list data types?"
msgstr "なぜタプルとリストという別のデータ型が用意されているのですか？"

#: ../../faq/design.rst:408
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:415
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, :func:`os.listdir('.') <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 ""
"一方、リストは、もっと他の言語の配列に近いものです。全て同じ型の可変数のオブ"
"ジェクトを持ち、それらが一つ一つ演算される傾向にあります。例えば、 :func:`os."
"listdir('.') <os.listdir>` はカレントディレクトリ内にあるファイルの文字列表現"
"のリストを返します。この出力を演算する関数は一般に、ディレクトリに一つや二つ"
"の別のファイルを加えても壊れません。"

#: ../../faq/design.rst:423
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:430
msgid "How are lists implemented in CPython?"
msgstr "CPythonでリストはどのように実装されているのですか？"

#: ../../faq/design.rst:432
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:436
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:439
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:446
msgid "How are dictionaries implemented in CPython?"
msgstr "CPythonで辞書はどのように実装されていますか？"

#: ../../faq/design.rst:448
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:452
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:463
msgid "Why must dictionary keys be immutable?"
msgstr "なぜ辞書のキーはイミュータブルでなくてはならないのですか？"

#: ../../faq/design.rst:465
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:474
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:478
msgid "Some unacceptable solutions that have been proposed:"
msgstr "いくつかの受け入れられなかった提案:"

#: ../../faq/design.rst:480
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:483
msgid ""
"mydict = {[1, 2]: '12'}\n"
"print(mydict[[1, 2]])"
msgstr ""

#: ../../faq/design.rst:486
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:490
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:494
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:499
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:505
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:`~object.__eq__` and a :meth:`~object.__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:`~object.__eq__` と :meth:`~object.__hash__` メ"
"ソッドの両方を持つクラスインスタンスに含めることができます。その時、辞書 (ま"
"たはハッシュに基づく別の構造体) に属するような全てのラッパーオブジェクトの"
"ハッシュ値が、そのオブジェクトが辞書 (その他の構造体) 中にある間固定され続け"
"ることを確実にしてください。 ::"

#: ../../faq/design.rst:513
msgid ""
"class ListWrapper:\n"
"    def __init__(self, the_list):\n"
"        self.the_list = the_list\n"
"\n"
"    def __eq__(self, other):\n"
"        return self.the_list == other.the_list\n"
"\n"
"    def __hash__(self):\n"
"        l = self.the_list\n"
"        result = 98767 - len(l)*555\n"
"        for i, el in enumerate(l):\n"
"            try:\n"
"                result = result + (hash(el) % 9999999) * 1001 + i\n"
"            except Exception:\n"
"                result = (result % 7777777) + i * 333\n"
"        return result"
msgstr ""

#: ../../faq/design.rst:530
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:534
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:539
msgid ""
"In the case of :class:`!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 ""
"この :class:`!ListWrapper` の例では、異常を避けるため、ラッパオブジェクトが辞"
"書内にある限りラップされたリストが変更されてはなりません。この条件と満たせな"
"かった時の結果について知恵を絞る覚悟がない限り、これをしてはいけません。よく"
"考えてください。"

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

#: ../../faq/design.rst:548
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:554
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:559
msgid ""
"for key in sorted(mydict):\n"
"    ...  # do whatever with mydict[key]..."
msgstr ""

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

#: ../../faq/design.rst:566
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:571
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:578
msgid ""
"For Python, many of the advantages of interface specifications can be "
"obtained by an appropriate test discipline for components."
msgstr ""
"Pythonでは、インターフェース仕様の多くの利点は、コンポーネントへの適切なテス"
"ト規律により得られます。"

#: ../../faq/design.rst:581
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:589
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:`!list.append` method is expected to "
"add new elements to the end of some internal list; an interface "
"specification cannot test that your :meth:`!list.append` implementation will "
"actually do this correctly, but it's trivial to check this property in a "
"test suite."
msgstr ""
"Python で大きくて複雑なアプリケーションを構築するとき、インターフェース仕様と"
"同様に、適切なテスト規律も役立ちます。実際には、インターフェース仕様ではテス"
"トできないプログラムの属性もあるので、それ以上にもなりえます。例えば、 :meth:"
"`!list.append` メソッドは新しい要素をある内部リストの終わりに加えます。イン"
"ターフェース仕様ではこの :meth:`!list.append` の実装が実際にこれを行うかをテ"
"ストできませんが、テストスイートならこの機能を簡単に確かめられます。"

#: ../../faq/design.rst:597
msgid ""
"Writing test suites is very helpful, and you might want to design your code "
"to make it easily tested. One increasingly popular technique, test-driven "
"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:605
msgid "Why is there no goto?"
msgstr "なぜ goto が無いのですか？"

#: ../../faq/design.rst:607
msgid ""
"In the 1970s people realized that unrestricted goto could lead to messy "
"\"spaghetti\" code that was hard to understand and revise. In a high-level "
"language, it is also unneeded as long as there are ways to branch (in "
"Python, with :keyword:`if` statements and :keyword:`or`, :keyword:`and`, "
"and :keyword:`if`/:keyword:`else` expressions) and loop (with :keyword:"
"`while` and :keyword:`for` statements, possibly containing :keyword:"
"`continue` and :keyword:`break`)."
msgstr ""
"1970年代、人々は気付きました。秩序なき goto は、理解するのも手直しするのも困"
"難という厄介な\"スパゲッティ\"コードに陥りがちであると。\n"
"高水準言語では、分岐とループの手段があれば goto は不要です。\n"
"(Pythonだと、分岐には :keyword:`if` 文及び :keyword:`or` ・ :keyword:`and` "
"・ :keyword:`if`/:keyword:`else` 式を使います。ループには :keyword:`while` 文"
"と :keyword:`for` 文を使い、 ループ内に :keyword:`continue` ・ :keyword:"
"`break` を含むことがあります)"

#: ../../faq/design.rst:614
msgid ""
"One can also use exceptions to provide a \"structured goto\" that works even "
"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:620
msgid ""
"class label(Exception): pass  # declare a label\n"
"\n"
"try:\n"
"    ...\n"
"    if condition: raise label()  # goto label\n"
"    ...\n"
"except label:  # where to goto\n"
"    pass\n"
"..."
msgstr ""

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

#: ../../faq/design.rst:637
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:641
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:648
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:651
msgid "f = open(\"/mydir/file.txt\")  # works fine!"
msgstr ""

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

#: ../../faq/design.rst:655
msgid ""
"dir = r\"\\this\\is\\my\\dos\\dir\" \"\\\\\"\n"
"dir = r\"\\this\\is\\my\\dos\\dir\\ \"[:-1]\n"
"dir = \"\\\\this\\\\is\\\\my\\\\dos\\\\dir\\\\\""
msgstr ""

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

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

#: ../../faq/design.rst:667
msgid ""
"with obj:\n"
"    a = 1               # equivalent to obj.a = 1\n"
"    total = total + 1   # obj.total = obj.total + 1"
msgstr ""

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

#: ../../faq/design.rst:673
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:678
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:684
msgid "For instance, take the following incomplete snippet::"
msgstr "例えば、以下の不完全なコード片を考えましょう::"

#: ../../faq/design.rst:686
msgid ""
"def foo(a):\n"
"    with a:\n"
"        print(x)"
msgstr ""

#: ../../faq/design.rst:690
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 :keyword:`with` block?  As "
"you see, the dynamic nature of Python makes such choices much harder."
msgstr ""
"このコード片では、``a`` は ``x``. というメンバ属性を持っていると仮定されてい"
"ます。しかし、Python ではインタプリタにはこの仮定を伝えられる仕組みはありませ"
"ん。 ``a`` が、例えば整数だったら、どうなってしまうでしょうか。 ``x`` という"
"名前のグローバル変数があったら、それが :keyword:`with` ブロックの中で使われる"
"のでしょうか。この通り、Python の動的な特質から、このような選択はとても難しい"
"物になっています。"

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

#: ../../faq/design.rst:699
msgid ""
"function(args).mydict[index][index].a = 21\n"
"function(args).mydict[index][index].b = 42\n"
"function(args).mydict[index][index].c = 63"
msgstr ""

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

#: ../../faq/design.rst:705
msgid ""
"ref = function(args).mydict[index][index]\n"
"ref.a = 21\n"
"ref.b = 42\n"
"ref.c = 63"
msgstr ""

#: ../../faq/design.rst:710
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:714
msgid ""
"Similar proposals that would introduce syntax to further reduce code volume, "
"such as using a 'leading dot', have been rejected in favour of explicitness "
"(see https://mail.python.org/pipermail/python-ideas/2016-May/040070.html)."
msgstr ""
"似た提案として、「先頭のドット」を使うなどして さらにコード量を減らす構文は、"
"明白さを優先をして却下されました (https://mail.python.org/pipermail/python-"
"ideas/2016-May/040070.html 参照)。"

#: ../../faq/design.rst:720
msgid "Why don't generators support the with statement?"
msgstr "なぜジェネレータは with 文をサポートしないのですか？"

#: ../../faq/design.rst:722
msgid ""
"For technical reasons, a generator used directly as a context manager would "
"not work correctly.  When, as is most common, a generator is used as an "
"iterator run to completion, no closing is needed.  When it is, wrap it as :"
"func:`contextlib.closing(generator) <contextlib.closing>` in the :keyword:"
"`with` statement."
msgstr ""
"技術的な理由で、ジェネレータは直接コンテキストマネージャとして使ってもうまく"
"動きません。最も一般的なように、ジェネレータが最後まで回りきるイテレータとし"
"て使われる場合、クローズ処理は不要です。必要な場合は、 :keyword:`with` 文で :"
"func:`contextlib.closing(generator) <contextlib.closing>` のようにラップしま"
"す。"

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

#: ../../faq/design.rst:732
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:735
msgid ""
"if a == b\n"
"    print(a)"
msgstr ""

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

#: ../../faq/design.rst:740
msgid ""
"if a == b:\n"
"    print(a)"
msgstr ""

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

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

#: ../../faq/design.rst:757
msgid ""
"[1, 2, 3,]\n"
"('a', 'b', 'c',)\n"
"d = {\n"
"    \"A\": [1, 5],\n"
"    \"B\": [6, 7],  # last trailing comma is optional but good style\n"
"}"
msgstr ""

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

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

#: ../../faq/design.rst:775
msgid ""
"x = [\n"
"  \"fee\",\n"
"  \"fie\"\n"
"  \"foo\",\n"
"  \"fum\"\n"
"]"
msgstr ""

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