On 6/6/2014 12:37 PM, Brett Cannon wrote:
After Glyph and Alex's email about their asks for assisting in writing Python 2/3 code, it got me thinking about where in the toolchain various warnings and such should go in order to help direct energy to help develop whatever future toolchain to assist in porting.
There seems to be three places where issues are/can be caught once a project has embarked down the road of 2/3 source compatibility:
1. -3 warnings 2. Some linter tool 3. Failing tests
-3 warnings are things that we know are flat-out wrong and do not cause massive compatibility issues in the stdlib. For instance, warning that buffer() is not in Python 3 is a py3k warning -- Glyph made a mistake when he asked for it as a new warning -- is a perfect example of something that isn't excessively noisy and won't cause issues when people run with it.
But what about warning about classic classes? The stdlib is full of them and they were purposefully left alone for compatibility reasons. But there is a subtle semantic difference between classic and new-style classes,
A non-subtle difference is that old style classes do not have .__new__. I just ran into this when backporting an Idle test to 2.7. (I rewrote the test to avoid diverging the code). In retrospect, perhaps we should have added a global 'new-class future' -C switch, like -Q, and made sure that stdlib worked either way. People running 2and3 code could then run 2.x with the switch. Is is possible to add this now?
and so 2/3 code should consider switching
I do not not understand what you mean without a switch or furture statement available to switch from old to new in 2.7.
(this is when people chime in saying "this is why we want a 2.8 release!", but that still isn't happening). If this were made a py3k warning in 2.7 then the stdlib itself would spew out warnings which we can't change due to compatibility, so that makes it not useful (http://bugs.python.org/issue21231).
Don't issue the warning if the class is in the stdlib. If the warning is issued *after* creating class C: f = C.__module__.__file__ if classic(C) and (not 'lib' in f or 'site_packages' in f): warn(...) On Windows, the directory is 'Lib'; I presume it is lowercased everywhere. If not, adjust.
But as part of a lint tool specific to Python 2.7 that kind of warning would not be an issue and is easily managed and integrated into CI setups to make sure there are no regressions.
Lastly, there are things like string/unicode comparisons. http://bugs.python.org/issue21401 has a patch from VIctor which warns when comparing strings and unicode in Python 2.7. Much like the classic classes example, the stdlib becomes rather noisy due to APIs that handle either/or, etc. But unlike the classic classes example, you just can't systematically verify that two variables are always going to be str vs. unicode in Python 2.7 if they aren't literals. If people want to implement type constraint graphs for 2.7 code to help find them then that's great, but I personally don't have that kind of time. In this instance it would seem like relying on a project's unit tests to find this sort of problem is the best option.
With those three levels in mind, where do we draw the line between these levels? Take for instance the print statement. Right now there is no warning with -3. Do we add one and then update the 2.7 stdlib to prevent warnings being generated by the stdlib?
Make conditional as with class. We *could* change 'print s' to the exactly equivalent 'print(s)' (perhaps half the cases); 'print r, s' to "print('%s %s' % (r,s)), 'print 'xxxx', y' to "print('xxxx %s' % y), and so on. However, 'print
self.stdout, x', etc, does not translate to a pseudo-call. It would need transltion to "self.stdout.write(x+'\n')". Grepping 2.7.6 lib/*.py for print gives 1341 hits, with at least 1000 being actual print statements.
Or do we add it to some linter tool to pick up when people accidentally leave one in their code?
The reason I ask is since this is clear I'm willing to spearhead the tooling work we talked about at the language summit to make sure there's a clear path for people wanting to port which is as easy as (reasonably) possible, but I don't want to start on it until I have a clear indication of what people are going to be okay with.
-- Terry Jan Reedy