# SOME DESCRIPTIVE TITLE.

# Copyright (C) 2001 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.14\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2025-05-09 14:19+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"

"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:21

msgid ""

"if (x <= y)\n"

" x++;\n"

" y--;\n"

"z++;"

msgstr ""

"if (x <= y)\n"

" x++;\n"

" y--;\n"

"z++;"

#: ../../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 ""

">>> 1.2 - 1.0\n"

"0.19999999999999996"

#: ../../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 ""

"10 進数表記 (decimal) で簡単に表せる数値でも、その多くは 2 進浮動小数点数 "

"(binary) で正確に表現できません。 たとえば次では ::"

#: ../../faq/design.rst:75

msgid ">>> x = 1.2"

msgstr ">>> x = 1.2"

#: ../../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 "1.0011001100110011001100110011001100110011001100110011 (binary)"

#: ../../faq/design.rst:83

msgid "which is exactly::"

msgstr "で、正確には次の値です::"

#: ../../faq/design.rst:85

msgid "1.1999999999999999555910790149937383830547332763671875 (decimal)"

msgstr "1.1999999999999999555910790149937383830547332763671875 (decimal)"

#: ../../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 ""

"詳しくは、Python チュートリアルの :ref:`floating-point arithmetic <tut-fp-"

"issues>` の章を参照してください。"

#: ../../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 ""

"while chunk := fp.read(200):\n"

" print(chunk)"

#: ../../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 "\", \".join(['1', '2', '4', '8', '16'])"

#: ../../faq/design.rst:203

msgid "which gives the result::"

msgstr "結果はこうなります::"

#: ../../faq/design.rst:205

msgid "\"1, 2, 4, 8, 16\""

msgstr "\"1, 2, 4, 8, 16\""

#: ../../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 "\"1, 2, 4, 8, 16\".split(\", \")"

#: ../../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 ""

"try:\n"

" value = mydict[key]\n"

"except KeyError:\n"

" mydict[key] = getvalue(key)\n"

" value = mydict[key]"

#: ../../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 ""

"if key in mydict:\n"

" value = mydict[key]\n"

"else:\n"

" value = mydict[key] = getvalue(key)"

#: ../../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 ""

"functions = {'a': function_1,\n"

" 'b': function_2,\n"

" 'c': self.method_1}\n"

"\n"

"func = functions[value]\n"

"func()"

#: ../../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 ""

"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()"

#: ../../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 ""

"`Cython <https://cython.org/>`_ は、 オプションアノテーションを付けた 修正"

"バージョンの Python から C 拡張 にコンパイルします。 `Nuitka <https://"

"nuitka.net/>`_ は Python から C++ コードへの有望なコンパイラで、 フルセット"

"の Python 言語サポートを目指しています。"

#: ../../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 の標準実装である :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 ""

"ただし、他の実装（ `Jython <https://www.jython.org>`_ や `PyPy <https://pypy."

"org>`_ など）では、本格的なガベージコレクタのような別の仕組みを用いているかも"

"しれません。 この違いは微妙な移植の問題を起こす可能性があります。もし あなた"

"の Python コードが参照カウント実装の振る舞いに依存している場合には。"

#: ../../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 ""

"for file in very_long_list_of_files:\n"

" f = open(file)\n"

" c = f.read(1)"

#: ../../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 ""

"for file in very_long_list_of_files:\n"

" with open(file) as f:\n"

" c = f.read(1)"

#: ../../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 ""

"辞書のハッシュテーブルの実装は、キーを見つけるために、キー値から計算された"

"ハッシュ値を使います。もしキーがミュータブルなオブジェクトだったら、その値は"