[aldanor]

> why would you have strings that are not intended to be displayed to end user

Why would you not? E.g., you use pandas and columns all have names. Colors are typically also strings, etc. Thus you would often do things like

    grouped = df.groupby(['foo', 'bar'])['baz'].mean()

However, the parent's point, IIUC, is that he'd do

    grouped.plot(color='red', title="User-facing title.")

[Too]

Colors as strings is a perfect example of what i'm trying to question here. How do i know which colors that are valid? Run time error? No thanks. Reading online documentation[0]? No thanks. I'd rather have my auto-complete[0] tell me right away the available options and my compiler tell me if i misspelled 'turquoiuse'. A better solution for this is a color-class with a long list of predefined colors as constants, and since they are just constants they could have any underlying format, not necessarily a string. Even in a dynamic language such as python this should be preferred over random strings.

Then yes, there are valid uses, especially in ad-hoc scripts. Column names and dictionary keys are one of the gray zones, though again, in my experience once your project grows these are also usually better to code generate from your db schema or serialization protocol; either complete data structures, api-functions, or just a list of constants. Anyway, my point is not to ban strings entirely, it's to question what we use it for. If you use strings as data/identifiers so frequently that you need a special convention for them something smells quite fishy.

[0] Auto complete = More accessible form of documentation. Before someone starts screaming that i'm stupid for "ignoring documentation".