Refactor `import datetime` as `import datetime as dt`

[hugovk]

Follow on from https://github.com/jazzband/tablib/pull/568#discussion_r1375298382.

Refactor import datetime as import datetime as dt to avoid ambiguity between the datetime module and class:

• https://adamj.eu/tech/2019/09/12/how-i-import-pythons-datetime-module/

[codecov[bot]]

Codecov Report

Merging #569 (a63cb1a) into master (c0e52cf) will not change coverage. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #569   +/-   ##
=======================================
  Coverage   92.40%   92.40%           
=======================================
  Files          28       28           
  Lines        2938     2938           
=======================================
  Hits         2715     2715           
  Misses        223      223           

Files	Coverage Δ
tests/test_tablib.py	98.84% <100.00%> (ø)
tests/test_tablib_dbfpy_packages_utils.py	100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[claudep]

I'm a bit hesitant to touch dbfpy too much, as it is vendored code. I we were to update the vendored code to a more recent version, we would face a big diff. What do you think?

[hugovk]

Good point, I'll revert.

Shall we also rename the package directory to make it more obvious this is vendored?

For example, pip has _vendor:

• https://github.com/pypa/pip/tree/main/src/pip/_vendor

[claudep]

Shall we also rename the package directory to make it more obvious this is vendored?

Makes sense, as long as this doesn't introduce compatibility issues (but it should not at first sight).

[hugovk]

Shall we also rename the package directory to make it more obvious this is vendored?

Makes sense, as long as this doesn't introduce compatibility issues (but it should not at first sight).

Hmm, I guess in theory someone could be doing from tablib.packages import dbfpy...

[claudep]

That could happen, but frankly I don't see the use case. I let you judge if moving the package is worth it, considering that minor breakage.

[hugovk]

Normally this sort of thing should be preceded by a deprecation warning, but I think we're fine here.

And the next release is set to be a major release anyway for https://github.com/jazzband/tablib/issues/558, so let's go for it.