Title: Add CapWords classes to datetime module?
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.11
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: dougthor42, eric.smith
Priority: normal Keywords:

Created on 2021-06-14 18:00 by dougthor42, last changed 2021-06-15 00:47 by dougthor42. This issue is now closed.

Messages (5)
msg395830 - (view) Author: Douglas Thor (dougthor42) Date: 2021-06-14 18:00
Has there been any discussion on adding CapWords class names to the 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.


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.

+ 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.

- 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"
- ???
msg395834 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2021-06-14 18:19
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.
msg395855 - (view) Author: Douglas Thor (dougthor42) Date: 2021-06-15 00:21
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.
msg395856 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2021-06-15 00:26
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.
msg395857 - (view) Author: Douglas Thor (dougthor42) Date: 2021-06-15 00:47
Thanks for the info!

Rejecting issue, as it would not be feasible to maintain going forward.
Date User Action Args
2021-06-15 00:47:23dougthor42setstatus: open -> closed
resolution: rejected
messages: + msg395857

stage: resolved
2021-06-15 00:26:11eric.smithsetmessages: + msg395856
2021-06-15 00:21:39dougthor42setmessages: + msg395855
2021-06-14 18:19:53eric.smithsetnosy: + eric.smith

messages: + msg395834
versions: - Python 3.6, Python 3.7, Python 3.8, Python 3.9, Python 3.10
2021-06-14 18:00:51dougthor42create