Removing wrong-import-position Pylint ignore statements.

[dhermes]

Able to address by reducing the complexity of the except blocks to make Pylint happy.

@tseaver This was a follow up to #1248, which I realized was possible after filing some issues with the Pylint folks.

[tseaver]

Moving the imports away from the fallback implementations doesn't seem to be a win: let's just disable the check globally.

[dhermes]

It doesn't seem to be a loss either. I had never questioned it before, but moving complexity out of try/except ImportError blocks isn't a bad goal to have.

By turning it off we miss out on the goodness of having stdlib > third party > local imports

[tseaver]

I don't mind ordering the imports that way, but don't believe the dogma that "code must not be in the import section," when it forces us to move the knowledge of the alternative elsewhere. Turning off the checker seems a higher quality result than making the changes with which this PR propitiates it.

[dhermes]

I don't mind ordering the imports that way

That puts the onus on us to remember, rather than letting us rely on a machine.

---

I think calling it dogma is a bit dramatic. We have tools that help us. Sometimes we take the bad (here: slightly inconvenient) with the good. If the alternative is writing pylint, then this is a fine trade-off.

FWIW, I actually like the changes that this hard to understand lint failure encouraged.

[tseaver]

I'm arguing that the relatively low aesthetic value of nicely-sorted imports does not outweigh the damage of moving the fallback implementations far away from the imports they are about: this is a case where the new opinion of the pylint maintainers isn't worth the cost.

[dhermes]

OK. I'll put it in pylintrc_default. Can you check out #1256 so we can discuss some of the new pylint features?

IIRC @jonparrott used a separate lint check for import order?

[dhermes]

@tseaver PTAL

[tseaver]

LGTM