Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • pypy pypy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 676
    • Issues 676
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

April 05-07 - Mercurial Paris Conference 2023 - One day of workshop dedicated to Heptapod and Mercurial usage and workflow. There are still places available for both workshops and talks!

  • PyPyPyPy
  • pypypypy
  • Merge requests
  • !701

Fix DeprecationWarnings on __complex__ returning subclass

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Yannick Jadoul requested to merge topic/py3.7/py3.7-bpo-29894 into branch/py3.7 Feb 23, 2020
  • Overview 1
  • Commits 1
  • Pipelines 0
  • Changes 2

The changes introduced by 91a34a0db5d2 do not result the failing tests (see http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy-c-jit-linux-x86-64&build=6808&mod=lib-python.3.test.test_complex), as the warnings are raised at the wrong moment (when calling complex() on an instance of a subclass of complex, rather than when __complex__ returns an instance of a subclass).

Cfr. https://bugs.python.org/issue29894 and https://github.com/python/cpython/pull/798

I'm not sure if accessing w_z.realval and w_z.imagval for these subclass instances is correct, though? But while looking into that, I bumped into this (related?) discrepancy between CPython and PyPy:

class complex3(complex):
    def __new__(self, value=0j):
        return complex.__new__(self, 2*value)
    @property
    def real(self):
        return 0
    @property
    def imag(self):
        return 1

CPython:

>>> complex3(1j)
2j
>>> complex(complex3(1j))
2j

PyPy:

>>>> complex3(1j)
2j
>>>> complex(complex3(1j))
1j

This seems to be because CPython directly accesses the internal C representation (((PyComplexObject*)r)->cval), while PyPy goes for the real and imag fields (space.float(space.getattr(w_complex, space.newtext("real")))).

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: topic/py3.7/py3.7-bpo-29894