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

There's no enforcement here, this is a docs-only change. You can stillimport 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 classdatetime, especially in example code likedatetime.now().

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

I am in favor of changing the documentation so that they do not use thefrom datetime import ... syntax. I think thisimport 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 soimport datetime as dt would definitely help newcomers to distinguish between the module, the class, and the instace methoddatetime.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 to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker d3b6faf9758dce236d45c708a450437cdc3e97cd 3.13

GH-145583 is a backport of this pull request to the3.14 branch.

GH-145584 is a backport of this pull request to the3.13 branch.

There's a few other examples in other files we can update after this.

Please see PR#145640.