@akx imo that would change the standard usage of the existing get_locale_identifier function.
In this case it makes more sense to modify all call sites (there are several in this class) to use the @property but won't it just mean another layer of indirection?

I think @Chiifouu's solution is good for this case, it doesn't modify the existing standard but does decouple __str__ behavior from affecting the class, clean and straightforward, no need to modify the existing standard.

@nathaniel-kotzrenko-hs

imo that would change the standard usage of the existing get_locale_identifier function.

I don't see how - you'd use get_locale_identifier() to build an identifier from raw parts as before.

In this case it makes more sense to modify all call sites (there are several in this class)

As far as I can see, there's only one call site that uses the Locale instance's values, and that's __str__. Other call sites (Locale.parse, default_locale()) don't.

but won't it just mean another layer of indirection?

In my eyes, it'll be the one canonical way to get the instance's full locale identifier, even if __str__ is overridden.

To be clear, I mean Locale.__str__() should just return self._identifier, and places where str(locale) are being currently used should use locale._identifier. (I'm slightly hesitant about making it identifier, i.e. a public API.)