.. ==================================== Differences between PyPy and CPython ==================================== ==================================== PyPyとCPythonの違い ==================================== .. This page documents the few differences and incompatibilities between the PyPy Python interpreter and CPython. Some of these differences are "by design", since we think that there are cases in which the behaviour of CPython is buggy, and we do not want to copy bugs. このページはPyPy PythonインタープリターとCPythonとのわずかな違いと非互換性について説明します。 これらの違いのいくつかは「デザイン」であり、CPythonでのバグっぽい挙動に対して、 バグをコピーしたくないと思うからです。 .. Differences that are not listed here should be considered bugs of PyPy. ここに記載されていない違いは、PyPyのバグだと考えられます。 .. Extension modules ----------------- 拡張モジュール ----------------- .. List of extension modules that we support: サポートしている拡張モジュールのリスト: .. * Supported as built-in modules (in `pypy/module/`_): * 組み込みモジュールとしてサポート ( `pypy/module/`_): __builtin__ `__pypy__`_ _ast _bisect _codecs _collections `_continuation`_ `_ffi`_ _hashlib _io _locale _lsprof _md5 `_minimal_curses`_ _multiprocessing _random `_rawffi`_ _sha _socket _sre _ssl _warnings _weakref _winreg array binascii bz2 cStringIO clr cmath `cpyext`_ crypt errno exceptions fcntl gc imp itertools marshal math mmap operator oracle parser posix pyexpat select signal struct symbol sys termios thread time token unicodedata zipimport zlib .. When translated to Java or .NET, the list is smaller; see `pypy/config/pypyoption.py`_ for details. Javaか.NETへ変換する際には、より少なくなります。 詳細は `pypy/config/pypyoption.py`_ を参照して下さい。 .. When translated on Windows, a few Unix-only modules are skipped, and the following module is built instead: Windowsで解釈される際には、Unixのみのモジュールがいくつかスキップされ、以下のモジュールが代わりにビルドされます: _winreg Note that only some of these modules are built-in in a typical CPython installation, and the rest is from non built-in extension modules. This means that e.g. ``import parser`` will, on CPython, find a local file ``parser.py``, while ``import sys`` will not find a local file ``sys.py``. In PyPy the difference does not exist: all these modules are built-in. * Supported by being rewritten in pure Python (possibly using ``ctypes``): see the `lib_pypy/`_ directory. Examples of modules that we support this way: ``ctypes``, ``cPickle``, ``cmath``, ``dbm``, ``datetime``... Note that some modules are both in there and in the list above; by default, the built-in module is used (but can be disabled at translation time). * (できる限り ``ctypes`` を使って)ピュアPythonで書き直してサポート: `lib_pypy/`_ ディレクトリを参照。 この方法を使ってサポートしたモジュールの例: ``ctypes``, ``cPickle``, ``cmath``, ``dbm``, ``datetime`` いくつかのモジュールではそのモジュール内と上記のリストの両方で、標準により、 組み込みモジュールが使われる(、しかし解釈時には無効になる)ことに注意しなければなりません。 .. The extension modules (i.e. modules written in C, in the standard CPython) that are neither mentioned above nor in `lib_pypy/`_ are not available in PyPy. (You may have a chance to use them anyway with `cpyext`_.) 上で言及されていない、 `lib_pypy/`_ にもない拡張モジュール( 標準CPythonでのCで書かれたモジュール)はPyPyでは利用できません。 (`cpyext`_ を用いることで利用できるかもしれません。) .. the nonstandard modules are listed below... .. _`__pypy__`: __pypy__-module.html .. _`_continuation`: stackless.html .. _`_ffi`: ctypes-implementation.html .. _`_rawffi`: ctypes-implementation.html .. _`_minimal_curses`: config/objspace.usemodules._minimal_curses.html .. _`cpyext`: http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html .. Differences related to garbage collection strategies ---------------------------------------------------- GC(ガベージコレクション)戦略に関連する違い ---------------------------------------------------- .. Most of the garbage collectors used or implemented by PyPy are not based on reference counting, so the objects are not freed instantly when they are no longer reachable. The most obvious effect of this is that files are not promptly closed when they go out of scope. For files that are opened for writing, data can be left sitting in their output buffers for a while, making the on-disk file appear empty or truncated. PyPyで使われ、実行されているGCの多くは参照カウントに基づいていませんので、到達不可能になってもオブジェクトは即座に解放されません。 この影響により、スコープから出ても、ファイルが即座に閉じられません。 書き出し用に開いたファイルに対して、データをしばらく出力バッファに置いたままにすることができ、ディスク上のファイルを空、または、不完全に見えさせます。 .. Fixing this is essentially not possible without forcing a reference-counting approach to garbage collection. The effect that you get in CPython has clearly been described as a side-effect of the implementation and not a language design decision: programs relying on this are basically bogus. It would anyway be insane to try to enforce CPython's behavior in a language spec, given that it has no chance to be adopted by Jython or IronPython (or any other port of Python to Java or .NET, like PyPy itself). このことはGCで参照カウントアプローチを使わずに本質的に解決することは不可能です。 CPythonでの実装結果は明確に言語設計で決定したものではなく、実装の副作用として記述されています: これを当てにするプログラムは、基本的にいんちきです。 それにJythonかIronPython(または、PyPy自身のような、Java、または、.NETのいかなるPythonのポート)で採用する機会が全くないなら、 言語仕様に基づいてCPythonの振舞いを実装しようとするのは、正気の沙汰ではありません。 .. This affects the precise time at which ``__del__`` methods are called, which is not reliable in PyPy (nor Jython nor IronPython). It also means that weak references may stay alive for a bit longer than expected. This makes "weak proxies" (as returned by ``weakref.proxy()``) somewhat less useful: they will appear to stay alive for a bit longer in PyPy, and suddenly they will really be dead, raising a ``ReferenceError`` on the next access. Any code that uses weak proxies must carefully catch such ``ReferenceError`` at any place that uses them. これは ``__del__`` メソッドが呼ばれる正確な時間に影響し、PyPy(Jython, IronPythonでも)では信頼できません。 また、弱参照が予想より少し長く生き残るかもしれないことを意味します。 これは(weakref.proxy()が返すような)「弱いプロキシ」となり、あまり役にたちません。 PyPy上でほんの少しだけ長く生き残り、突然本当に死亡し、次のアクセスで ``ReferenceError`` を挙げます。 弱プロキシを使うすべてのコードのあらゆる場所で ``ReferenceError`` を注意深くキャッチしなけばなりません。 .. As a side effect, the ``finally`` clause inside a generator will be executed only when the generator object is garbage collected (see `issue 736`__). 副作用として、ジェネレーター内の ``finally`` 節はジェネレーターオブジェクトがGCされたときのみ実行されます。( `issue 736`__ 参照) .. __: http://bugs.pypy.org/issue736 .. There are a few extra implications for the difference in the GC. Most notably, if an object has a ``__del__``, the ``__del__`` is never called more than once in PyPy; but CPython will call the same ``__del__`` several times if the object is resurrected and dies again. The ``__del__`` methods are called in "the right" order if they are on objects pointing to each other, as in CPython, but unlike CPython, if there is a dead cycle of objects referencing each other, their ``__del__`` methods are called anyway; CPython would instead put them into the list ``garbage`` of the ``gc`` module. More information is available on the blog `[1]`__ `[2]`__. GCの違いによっていくつかの特別な影響があります。 一番顕著なのは、もしオブジェクトが ``__del__`` を持つ場合、PyPyでは ``__del__`` が一度以上呼ばれることはありません。: しかし、CPythonではオブジェクトを復活させ、再度死ぬならば、何回か同じ ``__del__`` を呼びます。 CPythonではお互いを射すオブジェクトでは ``__del__`` メソッドは「正しい」順番で呼ばれますが、CPythonとは異なり、お互いにオブジェクト参照する死のサイクルがあれば、それらの ``__del__`` メソッドはどこでも呼ばれます。 CPythonは代わりにgcモジュールの ``garbage`` リストにそれらを入れるでしょう。 詳しい情報はブログを参照して下さい。 `[1]`__ `[2]`__ .. __: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html .. __: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html .. Using the default GC called ``minimark``, the built-in function ``id()`` works like it does in CPython. With other GCs it returns numbers that are not real addresses (because an object can move around several times) and calling it a lot can lead to performance problem. ``minimark`` と呼ばれる標準GCを使うことで、ビルトイン関数 ``id()`` はCPythonと同様に動作します。 他のGCでは(オブジェクトが何度か移動できるので)実際のアドレスと異なる数字を返し、何度も呼ばれることでパフォーマンス問題を引き起こします。 .. Note that if you have a long chain of objects, each with a reference to the next one, and each with a ``__del__``, PyPy's GC will perform badly. On the bright side, in most other cases, benchmarks have shown that PyPy's GCs perform much better than CPython's. オブジェクトの長いチェインがあり、それぞれ次のオブジェクトの参照をもち、それぞれ ``__del__`` を持つ場合、 PyPy GCのパフォーマンスがひどく悪くなることに注意してください。 明るい言い方をすると、他のほとんどの場合では、ベンチマークがPyPy GCのパフォーマンスがCPythonよりはるかによくなります。 .. Another difference is that if you add a ``__del__`` to an existing class it will not be called:: 別の違いは、 ``__del__`` メソッドを既存のクラスに追加すると呼ばれないということです。 :: >>>> class A(object): .... pass .... >>>> A.__del__ = lambda self: None __main__:1: RuntimeWarning: a __del__ method added to an existing type will not be called .. Even more obscure: the same is true, for old-style classes, if you attach the ``__del__`` to an instance (even in CPython this does not work with new-style classes). You get a RuntimeWarning in PyPy. To fix these cases just make sure there is a ``__del__`` method in the class to start with. さらによりわかりづらいこと : インスタンスに ``__del__`` メソッドをつける場合、 旧スタイルクラスでは同じことをしてもエラーになりません。(CPythonでは新スタイルクラスの場合でさえも動作しません) PyPyでは実行時に警告が出ます。 この場合、初めからクラスに ``__del__`` メソッドを持つように修正してください。 .. Subclasses of built-in types ---------------------------- 組み込み型のサブクラス ---------------------------- .. Officially, CPython has no rule at all for when exactly overridden method of subclasses of built-in types get implicitly called or not. As an approximation, these methods are never called by other built-in methods of the same object. For example, an overridden ``__getitem__()`` in a subclass of ``dict`` will not be called by e.g. the built-in ``get()`` method. 「組み込み型のサブクラスの適切なオーバーライドメソッドがさりげなく呼ばれたり、 呼ばれなかったりする」場合の公式なCPythonの仕様はありません。 大体、これらのメソッドは同じオブジェクトの他の組み込みメソッドから決して呼ばれません。 例えば、 ``dict`` のサブクラスで ``__getitem__()`` をオーバーライドしても、組み込みの ``get()`` などから呼ばれません。 .. The above is true both in CPython and in PyPy. Differences can occur about whether a built-in function or method will call an overridden method of *another* object than ``self``. In PyPy, they are generally always called, whereas not in CPython. For example, in PyPy, ``dict1.update(dict2)`` considers that ``dict2`` is just a general mapping object, and will thus call overridden ``keys()`` and ``__getitem__()`` methods on it. So the following code prints ``42`` on PyPy but ``foo`` on CPython:: 前述の内容はCPythonでもPyPyでも正しいです。 違いは、組込み関数、または、メソッドが ``self`` ではない *別* のオブジェクトのオーバーライドされたメソッドを呼ぶ場合に起こります。 PyPyでは一般的にいつでも呼ばれますが、CPythonではそうではありません。 例えば、PyPyでは ``dict1.update(dict2)`` は ``dict2`` が一般的にオブジェクトにマッピングされ、 ``keys()`` と ``__getitem__()`` メソッドがオーバーライドされて呼ばれるとみなされます。 そのため、下のコードは PyPy では ``42`` を出力しますが、 CPython では ``foo`` を出力します。:: >>>> class D(dict): .... def __getitem__(self, key): .... return 42 .... >>>> >>>> d1 = {} >>>> d2 = D(a='foo') >>>> d1.update(d2) >>>> print d1['a'] 42 Mutating classes of objects which are already used as dictionary keys --------------------------------------------------------------------- Consider the following snippet of code:: class X(object): pass def __evil_eq__(self, other): print 'hello world' return False def evil(y): d = {x(): 1} X.__eq__ = __evil_eq__ d[y] # might trigger a call to __eq__? In CPython, __evil_eq__ **might** be called, although there is no way to write a test which reliably calls it. It happens if ``y is not x`` and ``hash(y) == hash(x)``, where ``hash(x)`` is computed when ``x`` is inserted into the dictionary. If **by chance** the condition is satisfied, then ``__evil_eq__`` is called. PyPy uses a special strategy to optimize dictionaries whose keys are instances of user-defined classes which do not override the default ``__hash__``, ``__eq__`` and ``__cmp__``: when using this strategy, ``__eq__`` and ``__cmp__`` are never called, but instead the lookup is done by identity, so in the case above it is guaranteed that ``__eq__`` won't be called. Note that in all other cases (e.g., if you have a custom ``__hash__`` and ``__eq__`` in ``y``) the behavior is exactly the same as CPython. .. Ignored exceptions ----------------------- 警告の無視 ----------------------- .. In many corner cases, CPython can silently swallow exceptions. The precise list of when this occurs is rather long, even though most cases are very uncommon. The most well-known places are custom rich comparison methods (like \_\_eq\_\_); dictionary lookup; calls to some built-in functions like isinstance(). めったに発生しない厄介なケースの多くで、CPythonは静かに例外を飲み込み、見えなくすることができます。 こうなるケースはたくさんありますが、ほとんどのケースはめったに起こりません。 もっとも有名なのは、カスタム比較メソッド(例 ``__eq__``)、辞書の検索、 ``isinstance()`` などの組み込み関数の呼び出しです。 .. Unless this behavior is clearly present by design and documented as such (as e.g. for hasattr()), in most cases PyPy lets the exception propagate instead. この挙動は(``hasattr()`` 用の例のように)デザインとドキュメントによって明確になっていませんので、 PyPyでは多くの場合に代わりに例外の伝播を行います。 .. Miscellaneous ------------- 寄せ集め ------------- .. * ``sys.setrecursionlimit()`` is ignored (and not needed) on PyPy. On CPython it would set the maximum number of nested calls that can occur before a RuntimeError is raised; on PyPy overflowing the stack also causes RuntimeErrors, but the limit is checked at a lower level. (The limit is currently hard-coded at 768 KB, corresponding to roughly 1480 Python calls on Linux.) * ``sys.setrecursionlimit()`` はPyPyでは(不要であり、)無視されます。 CPythonでは、コールのネスト数の最大値を設定します。 これを超えると実行エラーが起こります。 PyPyで他の実行エラーが原因でスタックがオーバーフローし、制限はより低レベルで チェックされます。 (制限は現在768KBでハードコードされ、Linux上では大体1480 Python callに相当します。) .. * assignment to ``__class__`` is limited to the cases where it works on CPython 2.5. On CPython 2.6 and 2.7 it works in a bit more cases, which are not supported by PyPy so far. (If needed, it could be supported, but then it will likely work in many *more* case on PyPy than on CPython 2.6/2.7.) * ``__class__`` への割り当てはCPython 2.5で動作する場合に制限されます。 CPython 2.6、2.7ではほんの少し多くの場合でも動作しますが、PyPyではいまのところサポートしていません。 (必要ならばサポート可能でしたが、PyPyではCPython 2.6/2.7よりも *たくさんの* 場合に動作します。) .. * the ``__builtins__`` name is always referencing the ``__builtin__`` module, never a dictionary as it sometimes is in CPython. Assigning to ``__builtins__`` has no effect. * ``__builtins__`` はいつも ``__builtin__`` モジュールを参照しますので、 その辞書はCPythonにはありません。 ``__builtins__`` への割り当ては影響がありません。 * Do not compare immutable objects with ``is``. For example on CPython it is true that ``x is 0`` works, i.e. does the same as ``type(x) is int and x == 0``, but it is so by accident. If you do instead ``x is 1000``, then it stops working, because 1000 is too large and doesn't come from the internal cache. In PyPy it fails to work in both cases, because we have no need for a cache at all. * Also, object identity of immutable keys in dictionaries is not necessarily preserved. .. include:: _ref.txt