On Mon, Feb 21, 2022 at 5:18 PM Petr Viktorin wrote:
Should we care about hacks/optimizations that rely on having the only
> reference (or all references), e.g. mutating a tuple if it has refcount
> 1? Immortal objects shouldn't break them (the special case simply won't
> apply), but this wording
On Fri, Feb 4, 2022 at 12:55 AM Eric V. Smith wrote:
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to HPy. So why not just focus on making HPy suitable
> for developing C extensions, leave the existing C API alone, and
> eventually abandon the existing
> If a project does R releases per year for P platforms that need to support V
> versions of Python, they would normally have to build R * P * V wheels.
> With a stable ABI, they could reduce that to R * P. That's the key point,
> right?
> Can HPy do that?
actually, it can do even better than tha
> Does HPy have any clear guidance or assistance for their users to keep
> it up to date?
not right now, because we are still somewhat in alpha mode and sometimes we
redesign the API and/or break compatibility. But the plan is of course to
stabilize at some point.
> I think it can be done with
On 10/19/2012 04:13 PM, Nick Coghlan wrote:
> On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni wrote:
>> Is that the real intended behavior?
>
> Given the way complex numbers interact with floats generally,
> returning a complex number with no imaginary component as a floating
&
Hi,
while fixing pypy to pass CPython 3.2 tests, I found what I think it's a
inconsistency in how CPython (both 2.7 and 3.2) handles __complex__:
>>> class Obj:
... def __complex__(self):
... return 2.0
...
>>> obj = Obj()
>>> complex(obj)
(2+0j)
>>>
>>> import cmath
>>> cmath.acos(ob
