>> Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
>> variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
>> the encoding. Example:
>
> That's good to know, thanks. Only leaves the case where setlocale
> is called again with a different value.

You mean changing the current locale encoding using setlocale(LC_CTYPE)? It doesn't affect the encoding used by Python for filenames (and other OS data). It is a design choice, but also mandatory to avoid mojibake. It was possible in Python 3.1 to set the filesystem encoding, but it doesn't solve any problem, whereas it leads to mojibake is most (or all?) cases. A very important property is: os.fsencode(os.fsdecode(name)) == name. It fails if the result of os.fsdecode(name) was stored before the encoding was changed.

Few C functions are affected by the locale encoding: strerror() and strftime() (tell me if there are others!). Python 3.2 used to filesystem encoding (so the locale encoding read at startup) for them, but it was wrong. I fixed this issue recently:  #13560 (see also #13619.