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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
