2to3 and print function
At the moment, fix_print.py does the Right Thing when it finds ``from __future__ import print_function``... But the 2to3 parser gets upset when print() is passed kwargs: $ cat x.py from __future__ import print_function print("Hello, world!", end=' ') $ 2to3 x.py ... RefactoringTool: Can't parse x.py: ParseError: bad input: type=22, value='=', context=('', (2, 26)) What would be the best way to start fixing this? #2412 is the related bug.
On Wed, Mar 19, 2008 at 12:04 PM, David Wolever <wolever@cs.toronto.edu> wrote:
At the moment, fix_print.py does the Right Thing when it finds ``from __future__ import print_function``... But the 2to3 parser gets upset when print() is passed kwargs: $ cat x.py from __future__ import print_function print("Hello, world!", end=' ') $ 2to3 x.py ... RefactoringTool: Can't parse x.py: ParseError: bad input: type=22, value='=', context=('', (2, 26))
What would be the best way to start fixing this?
#2412 is the related bug.
You can pass -p to refactor.py to fix this on a per-run basis. See r58002 (and the revisions it mentions) for a failed attempt to do this automatically.
On 19-Mar-08, at 6:44 PM, Collin Winter wrote:
You can pass -p to refactor.py to fix this on a per-run basis. See r58002 (and the revisions it mentions) for a failed attempt to do this automatically.
So, correct me if I'm wrong, but the relevant code is this: - try: - tree = self.driver.parse_string(data) - except parse.ParseError, e: - if e.type == token.EQUAL: - tree = self.printless_driver.parse_string(data) - else: - raise Why not, instead of trying both parsers, scan for a __future__ import, then do the Right Thing based on that?
On Wed, Mar 19, 2008 at 10:27 PM, David Wolever <wolever@cs.toronto.edu> wrote:
On 19-Mar-08, at 6:44 PM, Collin Winter wrote:
You can pass -p to refactor.py to fix this on a per-run basis. See r58002 (and the revisions it mentions) for a failed attempt to do this automatically.
So, correct me if I'm wrong, but the relevant code is this: - try: - tree = self.driver.parse_string(data) - except parse.ParseError, e: - if e.type == token.EQUAL: - tree = self.printless_driver.parse_string(data) - else: - raise
Why not, instead of trying both parsers, scan for a __future__ import, then do the Right Thing based on that?
Different use cases. Auto-detection based on __future__ would be a good thing to have (assuming that __future__ statement has actually been implemented :-). But the -p lag is for code that has already been converted to 3.0 (as far as print statements are concerned anyway) and hence doesn't have __future__ statements. This is mostly used in the standard library, where sometimes it is useful to run selected fixers again after a merge. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 20-Mar-08, at 2:15 AM, Guido van Rossum wrote:
On Wed, Mar 19, 2008 at 10:27 PM, David Wolever <wolever@cs.toronto.edu> wrote:
Why not, instead of trying both parsers, scan for a __future__ import, then do the Right Thing based on that? Different use cases. Auto-detection based on __future__ would be a good thing to have (assuming that __future__ statement has actually been implemented :-). The __future__ statement has been implemented, so __future__ auto- detection will come shortly :)
participants (3)
-
Collin Winter -
David Wolever -
Guido van Rossum