[Python-Dev] Smoothing the transition from Python 2 to 3 (original) (raw)
Mark Lawrence breamoreboy at yahoo.co.uk
Thu Jun 9 22:52:23 EDT 2016
- Previous message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Next message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 10/06/2016 00:43, Brett Cannon wrote:
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.
Given the above and that 2to3 appears to be unsupported* is there a case for deprecating it?
- There are 46 outstanding issues on the bug tracker. Is the above the reason for this, I don't know?
-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language.
Mark Lawrence
- Previous message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Next message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]