[Python-ideas] Smoothing transition to Python 3

[tritium-list at sdamon.com]

In my experience (and if this is wrong, ignore the rest of this message),
python 3 is faster than python 2.  Since these are hacks primarily to get
people off of python 2... you only really have to hit python 2 speeds.  A
minor performance hit is acceptable.

> -----Original Message-----
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon.com at python.org] On Behalf Of Random832
> Sent: Saturday, June 4, 2016 8:24 PM
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Smoothing transition to Python 3
> 
> On Sat, Jun 4, 2016, at 19:37, Guido van Rossum wrote:
> > The bytes -> int behavior is widely considered a mistake. We're just
> > not able to fix it without yet another round of layoffs ^W
> > deprecations. And I'm not ready for that -- not even Python 4 should
> > be allowed to change this unilaterally. Though maybe we could do
> > something with a __future__ import.
> 
> I did have some thoughts (in the discussion a week or so ago about int
> division returning float vs Fraction) on how a __future__ flag (which
> have to be file scoped) effecting a change in the behavior of an
> operator of a class could be implemented without a
> __truediv__/__floordiv__ dichotomy intended to stick around forever.
> 
> In this case: Change the actual behavior of bytes.__getitem__ (direct
> callers aren't important enough to matter) to return a 1-length bytes
> instance. Add a compile flag (enabled by default, disabled by the future
> import) which causes foo[bar] to become __oldgetitem__(foo, bar) where:
> 
> def __oldgetitem__(obj, i):
>     if isinstance(obj, bytes) and not isinstance(i, slice):
>         return ord(obj.__getitem__(i))
>     else:
>         return obj.__getitem__(i)
> 
> Or instead of literally calling a function, we could add another byte
> code that directly implements this behavior. The question is how big the
> performance hit is and how important is the performance of code that
> doesn't use the future import, considering dynamic typing means every []
> operator (except perhaps those statically knowable to be slices) goes
> through this.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/