I agree with Paul Moore's comment, we need not enforce such things.

There's no enforcement here, this is a docs-only change. You can still import datetime if you prefer. There are no stdlib (or linter) changes.

I also don't see consensus in the thread for this, from a rough count I gather more people are against the change.

I disagree. I see more people against code and linter changes, but maybe just a couple against docs changes. I see 12 supporting Terry's docs suggestion (plus him), and another couple also supporting via comments.

I'm in favor of changing these examples in the docs. It provides a clear distinction between the module and the class, while gently showing importing the module as a preference over importing the classes directly.

I do struggle with new Python learners hitting confusion about the different between the module and the class datetime, especially in example code like datetime.now().

I tend to use the from datetime import ... convention in my own code, but that's the convention that's most likely to cause datetime confusion for new learners.

I am in favor of changing the documentation so that they do not use the from datetime import ... syntax. I think this import datetime as dt convention is a good way to do that.

I read through all the changes and they look good to me. 👍

I'm also in favor of this change. Too many times my IDE bite me by importing the class instead of the module or vice-versa so import datetime as dt would definitely help newcomers to distinguish between the module, the class, and the instace method datetime.datetime.time!

Thanks @hugovk for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

Sorry, @hugovk, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker d3b6faf9758dce236d45c708a450437cdc3e97cd 3.13

GH-145583 is a backport of this pull request to the 3.14 branch.

GH-145584 is a backport of this pull request to the 3.13 branch.