On 20-Mar-08, at 2:15 AM, Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 10:27 PM, David Wolever
> <[EMAIL PROTECTED]> 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 _
On Wed, Mar 19, 2008 at 10:27 PM, David Wolever <[EMAIL PROTECTED]> 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
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:
-
On Wed, Mar 19, 2008 at 12:04 PM, David Wolever <[EMAIL PROTECTED]> 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_
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
