8000 bpo-46659: calendar uses locale.getlocale() by vstinner · Pull Request #31166 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

bpo-46659: calendar uses locale.getlocale() #31166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 7, 2022
Merged

bpo-46659: calendar uses locale.getlocale() #31166

merged 2 commits into from
Feb 7, 2022

Conversation

vstinner
Copy link
Member
@vstinner vstinner commented Feb 6, 2022

The calendar.LocaleTextCalendar and calendar.LocaleHTMLCalendar
classes module now use locale.getlocale(), instead of using
locale.getdefaultlocale(), if no locale is specified.

https://bugs.python.org/issue46659

The calendar.LocaleTextCalendar and calendar.LocaleHTMLCalendar
classes module now use locale.getlocale(), instead of using
locale.getdefaultlocale(), if no locale is specified.
@vstinner
Copy link
Member Author
vstinner commented Feb 6, 2022

@vstinner
Copy link
Member Author
vstinner commented Feb 6, 2022

Example with cal_locale.py attached to bpo-46659. Run the program in English, but switch to a french locale before creating the LocaleTextCalendar() instance.

Current behavior: calendar speaks English, even if the current LC_TIME locale is French:

$ LC_ALL=en_US.utf8 ./python cal_locale.py fr_FR.utf8
locale.getlocale()=('fr_FR', 'UTF-8')
locale.getdefaultlocale()=('en_US', 'UTF-8')
cal.locale=('en_US', 'UTF-8')
                                August 2022
  Monday    Tuesday   Wednesday   Thursday    Friday    Saturday    Sunday
     1          2          3          4          5          6          7
     8          9         10         11         12         13         14
    15         16         17         18         19         20         21
    22         23         24         25         26         27         28
    29         30         31

With this PR: calendar speaks French:

$ LC_ALL=en_US.utf8 ./python cal_locale.py fr_FR.utf8
locale.getlocale()=('fr_FR', 'UTF-8')
locale.getdefaultlocale()=('en_US', 'UTF-8')
cal.locale=('fr_FR', 'UTF-8')
                                 août 2022
  lundi      mardi     mercredi    jeudi     vendredi    samedi    dimanche
     1          2          3          4          5          6          7
     8          9         10         11         12         13         14
    15         16         17         18         19         20         21
    22         23         24         25         26         27         28
    29         30         31

Applications which don't call setlocale() to change the LC_ALL or LC_TIME locale are not affected.

@serhiy-storchaka
Copy link
Member

Would not be more correct to use locale.getlocale(locale.LC_TIME)?

@vstinner
Copy link
Member Author
vstinner commented Feb 7, 2022

With this PR, the two classes store the current locale when an instance is created. Is it really an important feature?

Or would it be acceptable to use the current locale (don't change the locale) if locale=None is passed (default behavior)?

@vstinner
Copy link
Member Author
vstinner commented Feb 7, 2022

Would not be more correct to use locale.getlocale(locale.LC_TIME)?

You're right: done.

@vstinner vstinner merged commit 7a0486e into python:main Feb 7, 2022
@vstinner vstinner deleted the calendar_defaultlocale branch February 7, 2022 23:24
@vstinner
Copy link
Member Author
vstinner commented Feb 7, 2022

Merged, thanks for your reviews.

With this PR, the two classes store the current locale when an instance is created. Is it really an important feature?

In case of doubt, I prefer to leave the code as it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0