You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal for additional conjunction parameter in natural_list function #214
Thank you for the new version; natural_list really resolves several issues.
Summary
I would like to propose an enhancement to the natural_list function. Currently, the output for the list [1, 2, 3] is formatted as "1, 2 and 3". I propose adding a parameter that allows users to choose between "and" or "or" in the output.
I checked the documentation and found in #103 that there is interest in implementing something like this issue.
Motivation
This enhancement would provide more flexibility in how lists are presented, particularly in contexts where the choice between "and" and "or" is significant.
Proposed Changes
Introduce a new parameter (e.g., conjunction) to the natural_list function.
Accept boolean values for this parameter:
True (default behavior)
False
Example Usage
With the proposed change, the usage would look like this:
fromhumanizeimportnatural_listprint(natural_list([1, 2, 3])) # Output: "1, 2 and 3"print(natural_list([1, 2, 3], conjunction=False)) # Output: "1, 2 or 3"
Another Idea
We could also consider adding or and and to the i18n support for multiple languages, but I believe that should be addressed in a separate issue.
I could submit the PR if there's interest, but I'm not sure if conjunction would be the best name for this parameter.
I find the idea of allowing any string as a conjunction interesting. However, I am a bit concerned about the issue of internationalization (i18n), as this may require users to implement their own gettext. For an initial solution, I think the proposal is quite valid.
As for the parameter name, I considered alternatives like connector or joiner, but I still haven’t found an option that stands out more than conjunction.
Additionally, my concern about i18n relates to another issue I would like to open (after resolving this one, which is a bug) regarding the case of empty lists. It would be ideal to return a generic message instead of something like "empty."
We don't currently have any i18n for this function, so that's a separate thing to address.
When i18n is added, I think it should be possible to add a couple of pre-baked options for common options like "and", "or". Beyond those, requiring the user to use gettext for their own custom text should be okay; we can't and shouldn't try to predict everything.
Additionally, my concern about i18n relates to another issue I would like to open (after resolving this one, which is a bug) regarding the case of empty lists. It would be ideal to return a generic message instead of something like "empty."
Activity
hugovk commentedon Oct 25, 2024
What do you think about a more general solution where you can specify the conjunction?
For example:
Also open to a different name for the parameter.
dunossauro commentedon Oct 25, 2024
Thank you for your response!
I find the idea of allowing any string as a conjunction interesting. However, I am a bit concerned about the issue of internationalization (i18n), as this may require users to implement their own
gettext. For an initial solution, I think the proposal is quite valid.As for the parameter name, I considered alternatives like
connectororjoiner, but I still haven’t found an option that stands out more thanconjunction.Additionally, my concern about i18n relates to another issue I would like to open (after resolving this one, which is a bug) regarding the case of empty lists. It would be ideal to return a generic message instead of something like "empty."
hugovk commentedon Oct 25, 2024
We don't currently have any i18n for this function, so that's a separate thing to address.
When i18n is added, I think it should be possible to add a couple of pre-baked options for common options like "and", "or". Beyond those, requiring the user to use
gettextfor their own custom text should be okay; we can't and shouldn't try to predict everything.👍
Merge pull request #3 from osalks/fix/issue-214-conjunction