[Python-Dev] return type of __complex__

[Brett Cannon]

On Fri, Oct 19, 2012 at 12:48 PM, Benjamin Peterson <benjamin at python.org>wrote:

> 2012/10/19 Tres Seaver <tseaver at palladion.com>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 10/19/2012 11:56 AM, Benjamin Peterson wrote:
> >> 2012/10/19 Tres Seaver <tseaver at palladion.com>:
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>
> >>> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
> >>>> 2012/10/19 Antonio Cuni <anto.cuni at gmail.com>:
> >>>>> indeed, you are right. So I suppose that in pypy we could just
> >>>>> relax the check in cmath and be happy. Is there any chance that
> >>>>> this will be changed in 2.7 and/or 3.x?
> >>>>
> >>>> Certainly 3.x, but not 2.7.
> >>>
> >>> Why not 2.7?  It is a perfectly-backward-compatible change:  no
> >>> currenly-working code could possibly break if cmath's restriction
> >>> was relaxed.
> >>
> >> It's a new feature.
> >
> > That is an assertion;  I can dqually assert that the current over-strict
> > typechecking is a bug, because it doesn't conform to the semandics of
> > 'comples_new'.
>
> Nobody claimed it did conform to semantics of complex_new.
>

This also leads to a voluntary dovetailing of what would be accepted
between bugfix releases. Anyone remember True/False coming into existence
between bugfix releases? Wasn't that fun?

And in case someone didn't pick up on the sarcasm, it wasn't fun and it's
why we don't widen acceptability of things between bugfix releases unless
it is actually breaking code as-is (which this isn't).


>
> >
> >> Also, it's possible that someone is relying on it throwing for
> >> non-complex values.
> >
> > No already working, non-contrived code would break, becuase float is
> > perfectly-promotable to complex.
>
> I'm not saying the code which would break is good, I'm just saying it
> shouldn't be broken in bugfix releases
>

Agreed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121019/43519187/attachment.html>