Default locale logical compatibility with Python 3.12

liushuyu commented 5 months ago

Description:

Related issue (if applicable): N/A

This pull request fixes the behavioural differences on Python 3.12, where if the default locale is unspecified, the new Python defaults to C.UTF-8 instead of en_US.UTF-8 on Unix systems.

Checklist

[X] The code change is tested and works locally.
[X] There is no commented out code in this PR.
[X] No lint errors (use flake8)
[X] 100% test coverage

Testing

Anyone can help test this source code as follows:

# Create a virtual environment to work in as follows:
python3 -m venv apprise

# Change into our new directory
cd apprise

# Activate our virtual environment
source bin/activate

# Install the branch
pip install git+https://github.com/caronc/apprise.git@<this.branch-name>

# Test out the changes with the following command:
apprise -t "Test Title" -b "Test Message" \
  <apprise url related to ticket>

codecov-commenter commented 5 months ago

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 99.26%. Comparing base (31a4f2e) to head (8115a10). Report is 34 commits behind head on master.

:exclamation: Current head 8115a10 differs from pull request most recent head 729f53e. Consider uploading reports for the commit 729f53e to get more accurate results

Files	Patch %	Lines
apprise/AppriseLocale.py	0.00%	1 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1054 +/- ## ========================================== - Coverage 99.27% 99.26% -0.02% ========================================== Files 135 135 Lines 17600 17602 +2 Branches 3592 3593 +1 ========================================== Hits 17472 17472 - Misses 119 120 +1 - Partials 9 10 +1 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

caronc commented 2 months ago

Ties to #1102; my only concern with this PR is it over-rides Python versions less than 3.12 which the test works fine for.

I think this PR may be a okay work-around for now but i'm not sure if fixing the language to us is always the solution (consider other countries). There must be a check next if lang == C; the question is what i next (how is it done in all previous versions)?

Consider this tweak but even then i still don't accept my own answer :slightly_smiling_face:

# Based on patch already here...
import sys

if lang == 'C' and sys.version_info[0] == 3 and sys.version_info[1] == 12:
    # Alternatively sys.version_info[1] >=3
    lang = 'en_US'  # I still question the hard-coded assignment to english.

There are discussions in the following spots that state that C.UTF-8 != en_US.UTF-8:

Stack Overflow
SuperUser: references Wikipedia (which i could not link/follow) stating that LANG=C is a means of disabling localization (not actually setting one).

I wonder if it would be better to just support C; store it and:

update Translation package to just no longer perform any translations at all. just return empty strings when asked upon.
Displaying 1 warning message (identifying working environment could not be detected).

That would handle the ambiguity i can't seem to let go of :wink: .

In the past, when building on different operating systems in different countries (Pre Python 3.12) when C is set, i'm curious what the strategies are taken, and what the language flips to? Perhaps it actually does hard-code it to en_us.utf-8 ?

Edit: Revisiting the code and the change made, i realize i'm already choosing en as a hard-coded language :eyes: :man_facepalming: . So with that, I just made one small patch to reference the same constant. I'll have to revisit my own rant another day.

caronc commented 2 months ago

Thank you @liushuyu for this PR, and sorry i took so long to merge it in. I do appreciate it! Thank you for also letting me have my "old man yelling at cloud" moment! :slightly_smiling_face:

liushuyu commented 1 month ago

Sorry for the late reply.

Thank you @liushuyu for this PR, and sorry i took so long to merge it in. I do appreciate it! Thank you for also letting me have my "old man yelling at cloud" moment! 🙂

No problem! I could understand the underlying Python change must be a headache for the project.

In the past, when building on different operating systems in different countries (Pre Python 3.12) when C is set, i'm curious what the strategies are taken, and what the language flips to? Perhaps it actually does hard-code it to en_us.utf-8 ?

Edit: Revisiting the code and the change made, i realize i'm already choosing en as a hard-coded language 👀 🤦‍♂️ . So with that, I just made one small patch to reference the same constant. I'll have to revisit my own rant another day.

Just add to this, I think the new Python behavior is more "correct": many other languages use C.utf-8 as the fallback locale to signify that the current environment does not currently have a locale set (but still allows the program to read/interpret/pass valid Unicode data through glibc when doing system I/O).

caronc / apprise