<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 9 Jun 2016 at 16:08 Neil Schemenauer <<a href="mailto:neil@python.ca">neil@python.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-06-09, Brett Cannon wrote:<br>
> On Thu, 9 Jun 2016 at 14:56 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
> > Once you switch to those now recommended more conservative migration<br>
> > tools, the tool suite you request already exists:<br>
> ><br>
> > - update your code with modernize or futurize<br>
> > - check it still runs on Python 2.7<br>
> > - check it doesn't generate warnings under 2.7's "-3" switch<br>
> > - check it passes "pylint --py3k"<br>
> > - check if it runs on Python 3.5<br>
> ><br>
><br>
> `python3.5 -bb` is best to help keep Python 2.7 compatibility, otherwise<br>
> what Nick said. :)<br>
<br>
I have to wonder if you guys actually ported at lot of Python 2<br>
code.</blockquote><br></div><div class="gmail_quote">Yes I have, including code that needed to be 2.4-3.4 compatible of all things. Plus I'm the author of the porting HOWTO so I know the edge cases pretty well.<br><br>I don't think you meant for what you said to sound insulting, Neil, but it did feel like it upon first reading.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe you somehow avoided the problematic behavior. Below is<br>
a pretty trival set of functions. The tools you recommend do not<br>
help at all. One problem is that the str literals should be bytes<br>
literals.</blockquote><div><br></div><div>At least for Modernize that's on purpose as it can't tell semantically what is meant to be binary data vs. textual ASCII data (which you obviously know, else you wouldn't be trying to add runtime warnings for this sort of stuff).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Comparison with None needs to be avoided.<br>
<br>
With Python 2 code runs successfully. With Python 3 the code<br>
crashes with a traceback. With my modified Python 3.6, the code<br>
runs successfully but generates the following warnings:<br>
<br>
test.py:13: DeprecationWarning: encoding bytes to str<br>
output.write('%d:' % len(s))<br>
test.py:14: DeprecationWarning: encoding bytes to str<br>
output.write(s)<br>
test.py:15: DeprecationWarning: encoding bytes to str<br>
output.write(',')<br>
test.py:5: DeprecationWarning: encoding bytes to str<br>
if c == ':':<br>
test.py:9: DeprecationWarning: encoding bytes to str<br>
size += c<br>
test.py:24: DeprecationWarning: encoding bytes to str<br>
data = data + s<br>
test.py:26: DeprecationWarning: encoding bytes to str<br>
if input.read(1) != ',':<br>
test.py:31: DeprecationWarning: default compare is depreciated<br>
if a > 0:<br>
<br>
It is very easy for me to find code written for Python 2 that will<br>
fail in the same way. According to you guys, there is no problem<br>
and we already have good enough tooling. ;-(<br></blockquote><div><br></div><div>That's not what I'm saying at all (nor what I think Nick is saying); more tooling to ease the transition is always welcomed. The point we are trying to make is 2to3 is not considered best practice anymore, and so targeting its specific output might not be the best use of your time. I'm totally happy to have your fork work out and help give warnings for situations where runtime semantics are the only way to know there will be a problem that static analyzing tools can't handle and have the porting HOWTO updated so that people can run their test suite with your interpreter to help with that final bit of porting. I personally just don't want to see you waste time on warnings that are handled by the tools already or ignore the fact that six, modernize, and futurize can help more than 2to3 typically can with the easy stuff when trying to keep 2/3 compatibility. IOW some of us have become allergic to the word "2to3" in regards to porting. :) But if you want to target 2to3 output then by all means please do and your work will still be appreciated.<br><br></div><div>And I should also mention in case you don't know -- and assuming I'm remembering correctly -- that adding new Py3kWarning cases to Python 2.7 is still allowed, so if there is a warning you want to add that makes sense to be upstream then we can consider adding it in Python 2.7.12 (or later).<br></div></div></div>