At the moment, fixers are run in alphabetical order -- but this poses a problem, because some depend on others (for example, fix_print will need to be run _before_ fix_future, because fix_print looks for the 'from __future__ import ...' statement. I'm tempted to simply change fix_future to fix_zz_future... But that has some obvious drawbacks. Alternately, if future is the only dependent module, it might be marginally cleaner to simply special-case it in refactor.get_all_fix_names. So, any better suggestions?
On Wed, Mar 19, 2008 at 1:01 PM, David Wolever <wolever@cs.toronto.edu> wrote:
At the moment, fixers are run in alphabetical order -- but this poses a problem, because some depend on others (for example, fix_print will need to be run _before_ fix_future, because fix_print looks for the 'from __future__ import ...' statement.
I'm tempted to simply change fix_future to fix_zz_future... But that has some obvious drawbacks. Alternately, if future is the only dependent module, it might be marginally cleaner to simply special-case it in refactor.get_all_fix_names.
So, any better suggestions?
I would create a list of fixers that need to go first in refactor.py and run those in order. If you wanted to get complex, you could add a requires member to fixes, but that is probably overkill.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.c...
So, any better suggestions? I would create a list of fixers that need to go first in refactor.py and run those in order. If you wanted to get complex, you could add a requires member to fixes, but that is probably overkill. Ok, so I was digging around a bit and there is the option to traverse
On 19-Mar-08, at 2:18 PM, Benjamin Peterson wrote: the tree in preorder or postorder. While the actual order does not matter in this case, what does matter is that the preorder fixers are run first -- so I've just dropped the print fixer in there (and commented everything). This isn't a great general solution... But, at the moment, there is no need for it to be. If the need for a general solution arises, that can be added :)
On Wed, Mar 19, 2008 at 11:01 AM, David Wolever <wolever@cs.toronto.edu> wrote:
At the moment, fixers are run in alphabetical order -- but this poses a problem, because some depend on others (for example, fix_print will need to be run _before_ fix_future, because fix_print looks for the 'from __future__ import ...' statement.
I'm tempted to simply change fix_future to fix_zz_future... But that has some obvious drawbacks. Alternately, if future is the only dependent module, it might be marginally cleaner to simply special-case it in refactor.get_all_fix_names.
So, any better suggestions?
I would fix the from-future fixer to not remove futures that are specific to 3.0, and let the fixers specific to those features remove them. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
participants (3)
-
Benjamin Peterson -
David Wolever -
Thomas Wouters