decouple.Csv() makes raw strings not-raw, incorrectly

[kojiromike]

The django-cors-headers middleware has two ways to control Access-Control-Allow-Origin. One of them is via a regular expression CORS_ALLOWED_ORIGIN_REGEXES, which is a list of strings that are regular expressions. Unfortunately, we've been struggling to use a regex like r"^https://\w+\.example\.com$". That is, we tried

>>> CORS_ALLOWED_ORIGIN_REGEXES: List[str] = config('CORS_ALLOWED_ORIGIN_REGEXES', r"^https://\w+\.example\.com$", cast=Csv())

and set the value in the environment, and that didn't work because…

>>> Csv()(r"^https://\w+\.example\.com$")
['^https://w+.example.com$']

which is not the same regular expression we entered. Honestly, the other side of our problem is helmfile, which makes it difficult to set environment variables with backslashes in them, but we thought at least the default in pure python should work, and would be worth reporting.

If you don't use Csv(), the raw string behaves as expected:

>>> config('XYZZY', r'abc\def')
'abc\\def'

[henriquebastos]

That's an interesting problem. Sure the inconsistency should be solved. Don't know yet what could be done with CSV.

Can you provide a PR with the desired failing tests and the expected results?

This would make easy for me to figure out what to do.

[kojiromike]

I will see what I can do to help!

[kojiromike]

Hi, I created #103 to tackle this bug. Please let me know if there's anything else I can do to help.

[kojiromike]

Hi, any chance of getting traction on this issue? I think the code is all ready to go in #103.

[henriquebastos]

Yes. But this is not an CSV issue. It's more general. I'll need to write the proper tests to make sure all the corners are covered.