Has there been any discussion on adding CapWords class names to the datetime.py module?

I searched through the bug tracker ("CapWords" and "CamelCase") and didn't find anything, but perhaps I'm not searching for the correct keywords.

Eg:

```
# datetime.py
class datetime:
    ...

class tzinfo:
    ...

...

DateTime = datetime
TzInfo = tzinfo
TimeZone = timezone
TimeDelta = timedelta
...
```


I'd imaging implementing this would be pretty trivial and wouldn't break any existing functionality. I'd be happy to implement it.


Benefits:
+ Starts down the road to naming conventions found in pep8.
+ Maybe makes discovery easier for new users? It can be confusing for new users when the same word "datetime" can refer to either a class or a module.
+ Can start a deprecation process for the all-lowercase class names if so desired (actually doing so is outside the scope of this discussion)
+ Makes it easy, at a glance, to tell if code is referring to `datetime` the module or `DateTime` the class.


Downsides:
- fragments future usage: there will be a split between people using `DateTime` and `datetime`. This makes it hard to do things like mass grep over codebase.
- "If it ain't broke, don't fix it"
- ???

Changing versions: this could only be added to 3.11.

I think the ship has sailed on this. The old names could never be removed so we'd have to support both names forever. I think it's not worth the hassle.

Thanks for correcting the version selection.

> the old names could never be removed ... it's not worth the hassle

I had the same thought, so I spent a lot of time trying to come up with "Benefits", haha.

I'm OK with this being closed as rejected.
Is there a standard procedure for doing so? Eg: "keep things open for at least 24hrs so that multiple people can see things" or "only members of <X> should close issues"? If not I'll just close it myself.

I suggest you close it. If you want some broader discussion, you should bring it up on the python-ideas mailing list, but I don't expect you'll get much support.

Thanks for the info!

Rejecting issue, as it would not be feasible to maintain going forward.