Mailman 3 February 2017 - pypy-issue

Issue #2488: Unable to list or find packages contributed by me. (pypy/pypy)
by Niraj Kumar Panda 27 Feb '17

27 Feb '17

New issue 2488: Unable to list or find packages contributed by me. https://bitbucket.org/pypy/pypy/issues/2488/unable-to-list-or-find-packages Niraj Kumar Panda: My pypy id is : nirajKpanda I am unable to list or find all packages being contributed by me.Is there any back end api or way available to find those ?

1 0

Issue #2487: Debugging RPython interpreter and cpyext code? (pypy/pypy)
by Denis Akhiyarov 27 Feb '17

27 Feb '17

New issue 2487: Debugging RPython interpreter and cpyext code? https://bitbucket.org/pypy/pypy/issues/2487/debugging-rpython-interpreter-a… Denis Akhiyarov: Is it possible to debug RPython code instead of generated C code in PyPy interpreter?

1 0

Issue #2486: PyPyType_Ready with tp_flags crashes PyPy interpreter (pypy/pypy)
by Denis Akhiyarov 26 Feb '17

26 Feb '17

New issue 2486: PyPyType_Ready with tp_flags crashes PyPy interpreter https://bitbucket.org/pypy/pypy/issues/2486/pypytype_ready-with-tp_flags-cr… Denis Akhiyarov: I'm trying to debug PyPy crash with pythonnet library. PyPyType_Ready(type) works if no tp_flags are set on this type. If any basic flag is set (e.g. Py_TPFLAGS_DEFAULT_EXTERNAL) this crashes interpreter. Are there any differences between CPython and PyPy wrt to setting tp_flags? Here is a typical crash: https://github.com/pythonnet/pythonnet/issues/330#issuecomment-280820452 ``` >>>> import clr Attempting to load 'Python.Runtime' using standard binding rules. 'Python.Runtime' not found using standard binding rules. Attempting to load Python.Runtime from: 'C:\Python\pypy-c-jit-latest-win32\site-packages\Python.Runtime.dll'. Success loading 'Python.Runtime' from: 'C:\Python\pypy-c-jit-latest-win32\site-packages\Python.Runtime.dll'. RPython traceback: File "pypy_module_cpyext_2.c", line 25519, in type_realize File "pypy_module_cpyext_2.c", line 30900, in _type_realize Fatal RPython error: AssertionError ```

1 0

Issue #2485: End of support of PyPy (pypy/pypy)
by Artur Barseghyan 26 Feb '17

26 Feb '17

New issue 2485: End of support of PyPy https://bitbucket.org/pypy/pypy/issues/2485/end-of-support-of-pypy Artur Barseghyan: I could not find any information on this. What is the end of support of PyPy? Will it be supported longer than Python2? Or does it follow the same deprecation policy as Python2? Please, mention in docs and FAQ.

1 0

Issue #2484: PyHeapTypeObject difference with CPython (pypy/pypy)
by Denis Akhiyarov 24 Feb '17

24 Feb '17

New issue 2484: PyHeapTypeObject difference with CPython https://bitbucket.org/pypy/pypy/issues/2484/pyheaptypeobject-difference-wit… Denis Akhiyarov: Why does PyPy skip _heaptypeobject when compared with CPython: typedef struct _heaptypeobject {} https://github.com/python/cpython/blob/2.7/Include/object.h#L415 https://github.com/mozillazg/pypy/blob/master/pypy/module/cpyext/parse/cpye… This complicates libraries that parse CPython/PyPy headers.

1 0

Issue #2483: clang complains about parsing pypy headers (pypy/pypy)
by Denis Akhiyarov 24 Feb '17

24 Feb '17

New issue 2483: clang complains about parsing pypy headers https://bitbucket.org/pypy/pypy/issues/2483/clang-complains-about-parsing-p… Denis Akhiyarov: pypy 2.7, linux 64. Calling with clang and fake_libc_include from pycparser: ``` CalledProcessError: Command '['clang', '-I', 'tools/geninterop/fake_libc_include', '/home/dta/Downloads/pypy-c-jit-linux64/include', '-D', '__attribute__(x)=', '-D', '__inline__=inline', '-D', '__asm__=;#pragma asm', '-D', '__int64=long long', '-E', '/home/dta/Downloads/pypy-c-jit-linux64/include/Python.h']' returned non-zero exit status 1 ``` ``` #!python clang: warning: /home/dta/Downloads/pypy-c-jit-linux64/include: 'linker' input unused /home/dta/Downloads/pypy-c-jit-linux64/include/Python.h:76:10: error: 'pypy_macros.h' file not found with <angled> include; use "quotes" instead #include <pypy_macros.h> ^~~~~~~~~~~~~~~ "pypy_macros.h" In file included from /home/dta/Downloads/pypy-c-jit-linux64/include/Python.h:81: /home/dta/Downloads/pypy-c-jit-linux64/include/object.h:10:10: error: 'cpyext_object.h' file not found with <angled> include; use "quotes" instead #include <cpyext_object.h> ^~~~~~~~~~~~~~~~~ "cpyext_object.h" In file included from /home/dta/Downloads/pypy-c-jit-linux64/include/Python.h:112: /home/dta/Downloads/pypy-c-jit-linux64/include/unicodeobject.h:8:10: error: 'cpyext_unicodeobject.h' file not found with <angled> include; use "quotes" instead #include <cpyext_unicodeobject.h> ^~~~~~~~~~~~~~~~~~~~~~~~ "cpyext_unicodeobject.h" /home/dta/Downloads/pypy-c-jit-linux64/include/Python.h:140:12: error: 'pypy_decl.h' file not found with <angled> include; use "quotes" instead #include <pypy_decl.h> ^~~~~~~~~~~~~ "pypy_decl.h" 4 errors generated. ```

1 0

Issue #2482: cpyext: tp_basicsize only considers first base class to determine derived tp_basicsize (pypy/pypy)
by Jason Rhinelander 24 Feb '17

24 Feb '17

New issue 2482: cpyext: tp_basicsize only considers first base class to determine derived tp_basicsize https://bitbucket.org/pypy/pypy/issues/2482/cpyext-tp_basicsize-only-consid… Jason Rhinelander: When using multiple inheritance to inherit from both a Python object and an extension object (with a larger `tp_basicsize`) the `tp_basicsize` is the correct (larger) size only if the extension object is inherited first. For example, if `CBase` is an extension object with `tp_basicsize = 48` and the basic Python object size is 24 (as it seems to be for PyPy on my system) then with this code: ```Python class PyBase(object): pass class A(CBase, PyBase): pass class B(PyBase, CBase): pass a = A() b = B() ``` will call `CBase->tp_new` is called for the `A()` constructor, it'll be called with the `PyTypeObject *obj` having `obj->tp_basicsize = 48` (correctly), but for the `B()` constructor it'll have `obj->tp_basicsize = 24`. Under CPython both get invoked with the correct 48. I'm fairly sure that the issue is in `module/cpyext/typeobject.py`, in `finish_type_2`: it calls `inherit_special()` to set `tp_basicsize` to the `tp_basicsize` using only `base` (and so never considers inherited classes beyond the first one).

1 0

Issue #2481: unicodedata does not protect against larger-than-0x10ffff values (pypy/pypy)
by Armin Rigo 23 Feb '17

23 Feb '17

New issue 2481: unicodedata does not protect against larger-than-0x10ffff values https://bitbucket.org/pypy/pypy/issues/2481/unicodedata-does-not-protect-ag… Armin Rigo: You can get nonsense and potential crashes of unicodedata by doing this: ``` #!python >>>> u = array.array('u', 'abcd').tounicode() >>>> u u'\U64636261' >>>> u.isspace() ```

1 0

Issue #2480: cpyext tp_bases doesn't properly expose multiple inheritance (pypy/pypy)
by Jason Rhinelander 23 Feb '17

23 Feb '17

New issue 2480: cpyext tp_bases doesn't properly expose multiple inheritance https://bitbucket.org/pypy/pypy/issues/2480/cpyext-tp_bases-doesnt-properly… Jason Rhinelander: I'm working to extend pybind11's multiple inheritance support to allow multiple inheritance from the Python side (https://github.com/pybind/pybind11/pull/693), and ran into an issue where PyPy's `PyTypeObject.tp_bases` only contains the first parent class, e.g.: ``` class B1(object): pass class B2(object): pass class A(B1, B2): pass ``` cpyext code that gets the `PyTypeObject *` for `A` will have `tp_bases` set to a tuple of just `B1` instead of both `B1` and `B2`. `A.__bases__`, however, contains the correct types. My test code for this in this commit: https://github.com/jagerman/pybind11/commit/7e13ad2d044de7fd8641bac07ab7087… combined with this test code: ``` from __future__ import print_function from pybind11_tests import Base1, Base2, debug_tp_bases class A(object): pass class A2(object): pass class A3(A, A2): pass class B(Base1, Base2): def __init__(self): Base1.__init__(self, 1) Base2.__init__(self, 2) class C(A, B): def __init__(self): B.__init__(self) print("A.__bases__:", A.__bases__) debug_tp_bases(A) print("A3.__bases__:", A3.__bases__) debug_tp_bases(A3) print("B.__bases__:", B.__bases__) debug_tp_bases(B) print("C.__bases__:", C.__bases__) debug_tp_bases(C) ``` gives me (using current pypy nightly): ``` A.__bases__: (<type 'object'>,) Type `A' tp_bases: - object A3.__bases__: (<class '__main__.A'>, <class '__main__.A2'>) Type `A3' tp_bases: - A B.__bases__: (<class 'pybind11_tests.Base1'>, <class 'pybind11_tests.Base2'>) Type `B' tp_bases: - Base1 C.__bases__: (<class '__main__.A'>, <class '__main__.B'>) Type `C' tp_bases: - A ``` whereas CPython 2 and 3 give: ``` A.__bases__: (<type 'object'>,) Type `A' tp_bases: - object A3.__bases__: (<class '__main__.A'>, <class '__main__.A2'>) Type `A3' tp_bases: - A - A2 B.__bases__: (<class 'pybind11_tests.Base1'>, <class 'pybind11_tests.Base2'>) Type `B' tp_bases: - pybind11_tests.Base1 - pybind11_tests.Base2 C.__bases__: (<class '__main__.A'>, <class '__main__.B'>) Type `C' tp_bases: - A - B ```

1 0

Issue #2479: 'numpy.float64' objects are unhashable (pypy/pypy)
by Ronan Lamy 23 Feb '17

23 Feb '17

New issue 2479: 'numpy.float64' objects are unhashable https://bitbucket.org/pypy/pypy/issues/2479/numpyfloat64-objects-are-unhash… Ronan Lamy: need to investigate Responsible: rlamy

1 0