cc @feerrenrut @seanbudd While I'm pretty sure this PR is not going to break backward compatibility it would be nice to merge it before 2021.1 just to be on the safe side. It is very low impact yet eliminating cases in which particular order of imports is required is always good IMHO.

Thanks @lukaszgo1. I agree that the code should be moved, and these changes look like a good end result. When performing the other large code refactor we came up with some problems:

• addons which import things during the start of NVDA may trigger circular dependency issues. These changes might introduce a new one that will be hard to test for. It would be good to test this with some addons, just to catch any obvious issues.
• it would be good to have git blame track changes across the moved functions/types. Compare the output of git blame -M -C source\IAccessibleHandler\utils.py and git blame -M -C -w source\IAccessibleHandler\utils.py
  • if the whitespace changes are removed and added to a linting commit, we can set git blame to ignore this revision
  • we plan to make a ignore-revs file for this to fix Linting was disabled on speech.py #12377

With the other refactor, we removed linting so that a large linting change with an ignore-revs file wouldn't hold up the release. This might be a strategy to employ here, but at the very least the linting/whitespace changes should be done in a single commit if possible. Since this isn't an API breaking change, and we have very little holding back the release now, I think it's unlikely we will be able to squeeze this in.

* addons which import things during the start of NVDA may trigger circular dependency issues. These changes might introduce a new one that will be hard to test for. It would be good to test this with some addons, just to catch any obvious issues.

I've tested with my daily NVDA config (around 20 add-ons) and while this is not an exhaustive list by any means I haven't seen any errors aside from #12399 which is not caused by this PR.

* it would be good to have git blame track changes across the moved functions/types. Compare the output of `git blame -M -C source\IAccessibleHandler\utils.py` and `git blame -M -C -w  source\IAccessibleHandler\utils.py`
  
  * if the whitespace changes are removed and added to a linting commit, we can set git blame to ignore this revision

I'm not really sure why git blame fails to track these changes without ignoring white spaces since I've copied these functions verbatim (they were linted already). The only changes, aside from moving them, was to just add missing imports and copyright header to the new files. I agree that being able to track these moves is important so if you have a better idea for restructuring these commits so that git blame is able to detect these moves please do tell.

I've tested with my daily NVDA config (around 20 add-ons) and while this is not an exhaustive list by any means I haven't seen any errors aside from #12399 which is not caused by this PR.

Okay great, we should really add system tests for this as #12399 should not have been introduced.

I'm not really sure why git blame fails to track these changes without ignoring white spaces since I've copied these functions verbatim (they were linted already). The only changes, aside from moving them, was to just add missing imports and copyright header to the new files. I agree that being able to track these moves is important so if you have a better idea for restructuring these commits so that git blame is able to detect these moves please do tell.

I think your IDE or git is changing the line endings of old code with LF to CRLF. You can fix this by:

• temporarily setting git config core.autocrlf false
• doing a rebase on master and copy/pasting the functions again. I do this by pausing at a commit to amend and do the following
  • git checkout master fileNameOfSource (eg __init__.py)
  • git rm fileNameOfDest (eg types.py)
  • git mv fileNameOfSource fileNameOfDest
  • and then remove and unstage all the unwanted changes
  • then git commit --amend
• ensure your IDE isn't changing line endings - I do the above to avoid but there is likely a simpler way.
• at each step of the rebase comparing git blame -M -C source\IAccessibleHandler\utils.py and git blame -M -C -w source\IAccessibleHandler\utils.py
• changing your git settings back eg git config core.autocrlf true

I've done a rebase doing this if @feerrenrut or yourself could review?

I think your IDE or git is changing the line endings of old code with LF to CRLF.

Thanks - I'll investigate at which stage this fails on my machine to hopefully be able to avoid this issue next time. Assuming that this is changed by git and not by my editor can we enforce line endings through git config for all contributors?

I think your IDE or git is changing the line endings of old code with LF to CRLF.

Thanks - I'll investigate at which stage this fails on my machine to hopefully be able to avoid this issue next time. Assuming that this is changed by git and not by my editor can we enforce line endings through git config for all contributors?

This would be good to have, we would also like to normalize all files to CRLF and add the commit to an ignore-revs file at some point

Yep this looks ok. But I think there should be a description of these changes in the "for developers section", it may be unlikely, but we can't say it's impossible there are no addons relying on these things.