This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dougthor42
Recipients dougthor42
Date 2021-06-14.18:00:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1623693651.24.0.820963890692.issue44420@roundup.psfhosted.org>
In-reply-to
Content
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"
- ???
History
Date User Action Args
2021-06-14 18:00:51dougthor42setrecipients: + dougthor42
2021-06-14 18:00:51dougthor42setmessageid: <1623693651.24.0.820963890692.issue44420@roundup.psfhosted.org>
2021-06-14 18:00:51dougthor42linkissue44420 messages
2021-06-14 18:00:50dougthor42create