[Python-ideas] Smoothing transition to Python 3

[Neil Schemenauer]

On 2016-06-04, Nick Coghlan wrote:
> On 3 Jun 2016 13:17, "Neil Schemenauer" <nas-pythonideas at arctrix.com> wrote:
> > - comparision with None, smaller than all other types
> 
> Static type checkers should already be able to find these cases today,
> allowing them to be fixed incrementally pre-migration.

Really?  Please point me to them as I have about 100k lines of code
that needs to be checked.  I can't imagine how a static checker
could find this.

> > - comparision of distinct types: use Python 2 behavior (i.e. order
> >   by type name)
> 
> As above (and we definitely won't revert it - it's one of the more
> appreciated changes reported by educators)

I'm not proposing to revert it.  Sometimes I wonder if people
actually read my proposal.  I want a version of Python between 2.7.x
and 3.x that allows it with a warning.

Do you not see how such a version of Python is useful?  Why was the
whole __future__ mechanism designed in the first place?

> > - mixing of unicode strings with byte strings: decode/encode
> >   using latin-1
> 
> Converting with latin-1 would be even less correct than Python 2's
> behaviour of converting with ASCII (since it would allow arbitrary binary
> data to be implicitly interpreted as text)

I'm not sure how to best handle this, maybe UTF-8 would be better.
An implicit conversion only happens in the cases where Python 3
raises a TypeError.  Getting rid of the conversion is easy, make the
object either a str or bytes and call encode/decode as necessary.

> Type checkers don't generally help here yet, but are expected to in the
> future.

Python 3 was released in 2008.  How long until we have these tools
that help people to port their code?

> > - dict objects: make keys() items() values() return special sequence
> >   that warns if iterated over multiple times or indexed as sequence
> 
> These can be mechanically converted by futurize in a way that avoids a
> redundant copy on Python 2 (modernize will insert a redundant call to list
> for the Python 2 case)

I think you are correct.  Blindly putting list() calls around the
method calls works.  People can change their Python 2 code to iter*
if they want to avoid that.