Proposal for additional `conjunction` parameter in `natural_list` function

[dunossauro]

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

1. Introduce a new parameter (e.g., conjunction) to the natural_list function.
2. Accept boolean values for this parameter:
   • True (default behavior)
   • False

Example Usage

With the proposed change, the usage would look like this:

from humanize import natural_list

print(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.

[hugovk]

What do you think about a more general solution where you can specify the conjunction?

For example:

from humanize import natural_list

print(natural_list([1, 2, 3]))  # Output: "1, 2 and 3"
print(natural_list([1, 2, 3], conjunction="or"))  # Output: "1, 2 or 3"
print(natural_list([1, 2, 3], conjunction="and also"))  # Output: "1, 2 and also 3"

Also open to a different name for the parameter.

[dunossauro]

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

[hugovk]

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

👍