[Python-Dev] Smoothing the transition from Python 2 to 3

[Paul Moore]

On 10 June 2016 at 15:09, Cody Piersall <cody.piersall at gmail.com> wrote:
>> One problem is that the str literals should be bytes
>> literals.  Comparison with None needs to be avoided.
>>
>> With Python 2 code runs successfully.  With Python 3 the code
>> crashes with a traceback.  With my modified Python 3.6, the code
>> runs successfully but generates the following warnings:
>>
>>     test.py:13: DeprecationWarning: encoding bytes to str
>>       output.write('%d:' % len(s))
>>     test.py:14: DeprecationWarning: encoding bytes to str
>>       output.write(s)
>>     test.py:15: DeprecationWarning: encoding bytes to str
>>       output.write(',')
>>     test.py:5: DeprecationWarning: encoding bytes to str
>>       if c == ':':
>>     test.py:9: DeprecationWarning: encoding bytes to str
>>       size += c
>>     test.py:24: DeprecationWarning: encoding bytes to str
>>       data = data + s
>>     test.py:26: DeprecationWarning: encoding bytes to str
>>       if input.read(1) != ',':
>>     test.py:31: DeprecationWarning: default compare is depreciated
>>       if a > 0:
>>
>
> This seems _very_ useful; I'm surprised that other people don't think
> so too.  Currently, the easiest way to find bytes/str errors in a big
> application is by running the program, finding where it crashes,
> fixing that one line (or hopefully wherever the data entered the
> system if you can find it), and repeating the process.

It *is* very nice. But...

> This is nice because you can get in "fix my encoding errors" mode for
> more than just one traceback at a time; the new method would be to run
> the program, look at the millions of bytes/str errors, and fix
> everything that showed up in this round at once.  That seems like a
> big win for productivity to me.

If you're fixing encoding errors at the point they occur, rather than
looking at the high-level design of the program's handling of textual
and bytestring data, you're likely to end up in a bit of a mess no
matter how you locate the issues. Most likely because at the point in
the code where the warning occurs, you no longer know what the correct
encoding to use should be.

But absolutely, anything that gives extra information about where the
encoding hotspots are in your code is of value.
Paul