-
-
Notifications
You must be signed in to change notification settings - Fork 32
/
Copy pathdesign.po
1361 lines (1220 loc) · 73.5 KB
/
design.po
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2022, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
# Translators:
# Rafael Fontenelle <[email protected]>, 2022
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.10\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-12-30 14:59+0000\n"
"PO-Revision-Date: 2022-11-05 17:21+0000\n"
"Last-Translator: Rafael Fontenelle <[email protected]>, 2022\n"
"Language-Team: Japanese (https://www.transifex.com/python-doc/teams/5390/"
"ja/)\n"
"Language: ja\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
#: ../../faq/design.rst:3
msgid "Design and History FAQ"
msgstr "デザインと歴史 FAQ"
#: ../../faq/design.rst:6
msgid "Contents"
msgstr "内容"
#: ../../faq/design.rst:11
msgid "Why does Python use indentation for grouping of statements?"
msgstr "Python はなぜ文のグループ化にインデントを使うのですか？"
#: ../../faq/design.rst:13
msgid ""
"Guido van Rossum believes that using indentation for grouping is extremely "
"elegant and contributes a lot to the clarity of the average Python program. "
"Most people learn to love this feature after a while."
msgstr ""
"Guido van Rossum の信じるところによれば、インデントによるグループ化は非常にエ"
"レガントで、普通の Python プログラムを大いに読みやすくします。しばらくすれば"
"ほとんどの人はこの仕様を気に入るようになります。"
#: ../../faq/design.rst:17
msgid ""
"Since there are no begin/end brackets there cannot be a disagreement between "
"grouping perceived by the parser and the human reader. Occasionally C "
"programmers will encounter a fragment of code like this::"
msgstr ""
"開始/終了の括弧がないので、構文解析器と人間の読者の間にグループ化の解釈の違い"
"は起こりえません。時折、C のプログラマはこのようなコード片に出くわします::"
#: ../../faq/design.rst:26
msgid ""
"Only the ``x++`` statement is executed if the condition is true, but the "
"indentation leads 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: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 進数で簡単に書ける多くの数が、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:83
msgid "which is exactly::"
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 ""
"詳しくは、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:`__init__` methods, and in general in cases where a derived "
"class method wants to extend the base class method of the same name and thus "
"has to call the base class method somehow."
msgstr ""
"第二に、特定のクラスからメソッドを明示的に参照または呼び出ししたい時に、特別"
"な構文が必要なくなります。C++ では、派生クラスでオーバーライドされた基底クラ"
"スからメソッドを使うには、 ``::`` 演算子を使わなければなりません。 -- Python "
"では、 ``baseclass.methodname(self, <argument list>)`` と書けます。これは特"
"に、 :meth:`__init__` メソッドに便利ですし、派生クラスのメソッドが、基底クラ"
"スにある同じ名前のメソッドを拡張するために、基底クラスのメソッドをどうにかし"
"て呼び出したい時にも便利です。"
#: ../../faq/design.rst: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: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:207
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:203
msgid "which gives the result::"
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: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 try/except block is extremely efficient if no exceptions are raised. "
"Actually catching an exception is expensive. In versions of Python prior to "
"2.0 it was common to use this idiom::"
msgstr ""
"try/except ブロックは例外が送出されなければ極端に効率的です。実際に例外を捕捉"
"するのは高価です。Python 2.0 より前のバージョンでは、このイディオムを使うのが"
"一般的でした::"
#: ../../faq/design.rst:245
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:253
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:259
msgid "Why isn't there a switch or case statement in Python?"
msgstr "Python に switch や case 文がないのはなぜですか？"
#: ../../faq/design.rst:261
msgid ""
"You can do this easily enough with a sequence of ``if... elif... elif... "
"else``. For literal values, or constants within a namespace, you can also "
"use a ``match ... case`` statement."
msgstr ""
"``if... elif... elif... else`` の繰り返しで簡単に同じことができます。リテラル"
"値や名前空間内の定数には、``match ... case`` 文を使うこともできます。"
#: ../../faq/design.rst:265
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:276
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:288
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:294
msgid ""
"Can't you emulate threads in the interpreter instead of relying on an OS-"
"specific thread implementation?"
msgstr ""
"OS 特有のスレッド実装に依らずにインタプリタでスレッドをエミュレートすることは"
"できないのですか？"
#: ../../faq/design.rst:296
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:301
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:306
msgid "Why can't lambda expressions contain statements?"
msgstr "なぜラムダ式は文を含むことができないのですか?"
#: ../../faq/design.rst:308
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:314
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:322
msgid "Can Python be compiled to machine code, C or some other language?"
msgstr "Python は C やその他の言語のように機械語にコンパイルできますか？"
#: ../../faq/design.rst:324
msgid ""
"`Cython <https://cython.org/>`_ compiles a modified version of Python with "
"optional annotations into C extensions. `Nuitka <https://www.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://www.nuitka.net/>`_ はPythonをC+"
"+コードへ変換する将来有望なPythonコンパイラで、完全なPython言語をサポートする"
"ことを目的としています。"
#: ../../faq/design.rst:331
msgid "How does Python manage memory?"
msgstr "Python はメモリをどのように管理するのですか？"
#: ../../faq/design.rst:333
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:341
msgid ""
"Other implementations (such as `Jython <https://www.jython.org>`_ or `PyPy "
"<https://www.pypy.org>`_), however, can rely on a different mechanism such "
"as a full-blown garbage collector. This difference can cause some subtle "
"porting problems if your Python code depends on the behavior of the "
"reference counting implementation."
msgstr ""
"ただし、他の実装 (例えば `Jython <https://www.jython.org>`_ や `PyPy "
"<https://www.pypy.org>`_) は本格的 (full-blown) なガベージコレクタのような別"
"のメカニズムに依存するかもしれません。あなたの Python コードが参照カウントの"
"実装の振る舞いに依存する場合、この違いが微妙な移植上の問題を引き起こすでしょ"
"う。"
#: ../../faq/design.rst:347
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:354
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:359
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 "Why doesn't CPython use a more traditional garbage collection scheme?"
msgstr "CPython はなぜ伝統的なガベージコレクションスキームを使わないのですか？"
#: ../../faq/design.rst:371
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:377
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:386
msgid "Why isn't all memory freed when CPython exits?"
msgstr ""
"なぜ CPython の終了時にすべてのメモリが解放されるわけではないのですか？"
#: ../../faq/design.rst:388
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:395
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:400
msgid "Why are there separate tuple and list data types?"
msgstr "なぜタプルとリストという別のデータ型が用意されているのですか？"
#: ../../faq/design.rst:402
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:409
msgid ""
"Lists, on the other hand, are more like arrays in other languages. They "
"tend to hold a varying number of objects all of which have the same type and "
"which are operated on one-by-one. For example, ``os.listdir('.')`` returns "
"a list of strings representing the files in the current directory. "
"Functions which operate on this output would generally not break if you "
"added another file or two to the directory."
msgstr ""
"一方、リストは、もっと他の言語の配列に近いものです。全て同じ型の可変数のオブ"
"ジェクトを持ち、それらが一つ一つ演算される傾向にあります。例えば、 ``os."
"listdir('.')`` はカレントディレクトリ内にあるファイルの文字列表現のリストを返"
"します。この出力を演算する関数は一般に、ディレクトリに一つや二つの別のファイ"
"ルを加えても壊れません。"
#: ../../faq/design.rst:416
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:423
msgid "How are lists implemented in CPython?"
msgstr "CPythonでリストはどのように実装されているのですか？"
#: ../../faq/design.rst:425
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:429
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:432
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:439
msgid "How are dictionaries implemented in CPython?"
msgstr "CPythonで辞書はどのように実装されていますか？"
#: ../../faq/design.rst:441
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:445
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:456
msgid "Why must dictionary keys be immutable?"
msgstr "なぜ辞書のキーはイミュータブルでなくてはならないのですか？"
#: ../../faq/design.rst:458
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:467
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:471
msgid "Some unacceptable solutions that have been proposed:"
msgstr "いくつかの受け入れられなかった提案:"
#: ../../faq/design.rst:473
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:479
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:483
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:487
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:492
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:498
msgid ""
"There is a trick to get around this if you need to, but use it at your own "
"risk: You can wrap a mutable structure inside a class instance which has "
"both a :meth:`__eq__` and a :meth:`__hash__` method. You must then make "
"sure that the hash value for all such wrapper objects that reside in a "
"dictionary (or other hash based structure), remain fixed while the object is "
"in the dictionary (or other structure). ::"
msgstr ""
"必要ならばこれを回避する方法がありますが、自己責任のもとで行ってください。"
"ミュータブルな構造を、 :meth:`__eq__` と :meth:`__hash__` メソッドの両方を持"
"つクラスインスタンスに含めることができます。その時、辞書 (またはハッシュに基"
"づく別の構造体) に属するような全てのラッパーオブジェクトのハッシュ値が、その"
"オブジェクトが辞書 (その他の構造体) 中にある間固定され続けることを確実にして"
"ください。 ::"
#: ../../faq/design.rst:522
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:526
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:531
msgid ""
"In the case of ListWrapper, whenever the wrapper object is in a dictionary "
"the wrapped list must not change to avoid anomalies. Don't do this unless "
"you are prepared to think hard about the requirements and the consequences "
"of not meeting them correctly. Consider yourself warned."
msgstr ""
"この ListWrapper の例では、異常を避けるため、ラッパオブジェクトが辞書内にある"
"限りラップされたリストが変更されてはなりません。この条件と満たせなかった時の"
"結果について知恵を絞る覚悟がない限り、これをしてはいけません。よく考えてくだ"
"さい。"
#: ../../faq/design.rst:538
msgid "Why doesn't list.sort() return the sorted list?"
msgstr "なぜ list.sort() はソートされたリストを返さないのですか？"
#: ../../faq/design.rst:540
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:546
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` 関数を使ってく"