[Python-ideas] Smoothing transition to Python 3

[Nick Coghlan]

On 4 Jun 2016 8:06 am, "Neil Schemenauer" <nas-pythonideas at arctrix.com>
wrote:
>
> 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.

It depends on APIs being correctly flagged as returning Optional results
(although I don't know if the current crop of type checkers are clever
enough to know Optional values aren't orderable)

> > > - 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?

The -3 switch in Python 2.7 should already warn about these cases. If it
doesn't, new -3 warnings are permitted in 2.7 maintenance releases.

> > > - 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?

We already have a number of them, many linked from the porting guide in the
main documentation. python-future.org is one of the most comprehensive in
providing a Python 3 like experience atop Python 2 (but also most invasive
for existing Python 2 projects).

Red Hat's Python maintenance team are working on a more explicitly
minimalistic porting guide based on their experiences porting Fedora
components, sometimes in the context of upstream projects that are more
interested in keeping Python 2.4 support than they are in Python 3:
http://portingguide.readthedocs.io/en/latest/

For projects with the code coverage needed to facilitate significant
refactorings, these existing tools should be sufficient in most cases.
Where the static analysers being worked on by Dropbox, Google, etc are
likely to help most is with code bases that *don't* have that kind of test
coverage - good static analysis tools can help compensate for the gaps in
test coverage.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160604/64f99f3e/attachment-0001.html>