Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming bikeshedding thread #151

Open
1 of 4 tasks
ariebovenberg opened this issue Jul 9, 2024 · 3 comments
Open
1 of 4 tasks

Naming bikeshedding thread #151

ariebovenberg opened this issue Jul 9, 2024 · 3 comments
Labels
discussion Discussion is needed before proceeding enhancement New feature or request

Comments

@ariebovenberg
Copy link
Owner

ariebovenberg commented Jul 9, 2024

This is an issue to gather bikeshedding discussion about names. To keep churn minimal, any renames will be bundled as much as possible into a small number of releases.

Here are naming discussions. Items are only checked off when a decision has been made.

Comments are welcomed, but note that decisions are not (necessarily) made by majority vote

  • add Error suffix to exceptions: SkippedTime -> SkippedTimeError (and others)
  • rename py_datetime() to stdlib_datetime(), perhaps adding the to_ prefix?
  • Rename local() and instant() to to_local() and to_instant(). The original rationale was the the other to_* methods convert between "aware" types, while conversion to local or instant is more fundamental.
  • ...
@JaykeMeijer
Copy link
Collaborator

JaykeMeijer commented Jul 9, 2024

Regarding adding Error to exceptions: This is defined as common practice in the Python docs: https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions, is often mentioned as convention: https://www.geeksforgeeks.org/python-naming-conventions/, https://stackoverflow.com/questions/2903827/why-are-python-exceptions-named-error and is also part of PEP8: https://peps.python.org/pep-0008/#exception-names

I'm not convinced by stdlib_datetime(). Although it covers what it does, stdlib is not a term I'm used to seeing in a Python context and I might think it has something to do with some underlying/referenced C object. Looking at the next item on the list, should it include to_? Would to_datetime be too confusing? Perhaps to_python_datetime, to_standard_datetime or to_native_datetime?

I agree with the renaming of local() and instant()

@spacemanspiff2007
Copy link

I think to_local() and to_instant() makes sense because it changes the reference to another reference.

I think for importing/exporting to e.g. datetime another prefix should be used.
How about
create_datetime() or create_py_datetime()
I don't mind the exact naming, I think the important part is that it's possible to differentiate a conversion from a shift of the reference.

@ariebovenberg
Copy link
Owner Author

other prefixes that are often used are as_* or into_*, or in_*.

I'm a bit on the fence about mixing different styles of prefix. On the one hand, it can distinguish different 'flavors', but on the other hand, having one prefix is easier to discover. Realistically, most people will just type "to" in their IDE and read the list to see what the possible conversions are. They will just be confused why a different naming convention exists elsewhere.

@ariebovenberg ariebovenberg added the discussion Discussion is needed before proceeding label Jul 12, 2024
@ariebovenberg ariebovenberg added this to the API freeze (1.0) milestone Nov 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion is needed before proceeding enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants