[Python-ideas] Smoothing transition to Python 3

[tritium-list at sdamon.com]

Unless you changed your mind about version numbing (and the digit count in each slot of a version number), I don’t think we will be considering breaking changes till python 5 :)

I am totally unopposed to locking these kinds of shims/hacks/shames in a __future__ (__past__?) import.

> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf
> Of Guido van Rossum
> Sent: Saturday, June 4, 2016 7:38 PM
> To: Alexander Walters <tritium-list at sdamon.com>
> Cc: Neil Schemenauer <nas-pythonideas at arctrix.com>; Python-Ideas
> <python-ideas at python.org>
> Subject: Re: [Python-ideas] Smoothing transition to Python 3
> 
> 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.
> 
> On Sat, Jun 4, 2016 at 4:29 PM,  <tritium-list at sdamon.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> >> list=sdamon.com at python.org] On Behalf Of Neil Schemenauer
> >> Sent: Saturday, June 4, 2016 4:27 AM
> >> To: python-ideas at python.org
> >> Subject: Re: [Python-ideas] Smoothing transition to Python 3
> >>
> >> On 2016-06-04, tritium-list at sdamon.com wrote:
> >> > In fact most of the things you list here are the GOOD ideas
> >> > that python 3 enforces that reduces bugs when avoided in python 2.
> >>
> >> Sure, and I'm not proposing that standard Python 3.x change the
> >> behavior.
> >>
> >> > What would actually help the transition, in my world-view at least is
> >> >
> >> > * A bytes type like the string type in python 2 (*without implicit
> >> > conversion!*) There are too many real world use cases that the bytes
> > type
> >> > makes painful, including anything dealing with networking.
> >>
> >> The Python 3 bytes type should gain whatever features it needs to
> >> make things not painful.  The %-based formating in 3.5 is a big one.
> >> Is there something else you miss?
> >>
> >
> > b'Foo'[0] returning b'F' instead of the int 70
> >
> >> > * an alias to the string type named 'unicode' (this just makes polyglot
> > a
> >> > whole heck of a lot less stressful... yes I do this myself, it's
> > annoying,
> >> > if it was there by default, like bytes is in 2.7, it would make life a
> > lot
> >> > easier.  One just never just never references `str`)
> >>
> >> Maybe too late now but there should have been 'unicode',
> >> 'basestring' as aliases for 'str'.
> >>
> >> > * a "magic" mapping from old to new module names.  In my experience,
> >> this is
> >> > actually a bigger pain than it looks.
> >>
> >> I would like to add this to my "pragmatic" version.
> >>
> >> > The general response was the theme of the entire python 3
> >> > transition story:  "I don't see the value added."
> >>
> >> Yes, and here we are.  Python 3 is not yet winning and I'm not sure
> >> it will.  I believe Dropbox, Facebook and Google are all still using
> >> Python 2.  If porting code was so easy, why are they not moved over?
> >> I see VMWare released some new IoT SDK:
> >>
> >>     https://github.com/vmware/liota
> >>
> >> This is new code, written this year.  It is not compatible with
> >> Python 3 as far as I see.  I can't understand why people don't see
> >> we have a problem.
> >>
> >>   Neil
> >> _______________________________________________
> >> 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/
> >
> > _______________________________________________
> > 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/
> 
> 
> 
> --
> --Guido van Rossum (python.org/~guido)