gh-131146: Fix month names in a genitive case in calendar module

[plashchynski]

The calendar module displays month names in some locales using the genitive case. This is grammatically incorrect, as the nominative case should be used when the month is named by itself. To address this issue, this change introduces new lists alt_month_name and alt_month_abbr that contain month names in the nominative case. The module now uses %OB format specifier to get month names in the nominative case where available.

• Issue: calendar displays month names in a genitive case for some locales #131146

[ghost]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[tomasr8]

Thanks for the PR! This will also need a NEWS entry and tests (check Lib/test/test_calendar.py)

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 36bb456 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131147%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

Thank you for the PR, @plashchynski
If you don't beat me to it, I plan to fix the formatting/comments/entries tomorrow so that this gets into 3.14.

[StanFromIreland]

This also needs a proper test (my comment was incorrectly closed) using support's @run_with_locale, grep the existing tests for usage examples, there are quite a few.

[StanFromIreland]

I can finish this off if you are unable to, it should still be backported to 3.14 since it is a bug fix, no?

[plashchynski]

This also needs a proper test (my comment was incorrectly closed) using support's @run_with_locale, grep the existing tests for usage examples, there are quite a few.

The problem is specific only to certain locales. To properly test it, we need to have these locales installed. A test with @run_with_locale will fail only on systems where that locales are installed. So for most systems that test will be green without proposed changes. I think it's not worth to add tests that can't fail on most of the systems.

[StanFromIreland]

So for most systems that test will be green without proposed changes.

It will not pass, it will be skipped.

I think it's not worth to add tests that can't fail on most of the systems.

It is! Most systems have locale like pl_PL installed anyway, looking at the buildbots the majority do.

[plashchynski]

I think it's not worth to add tests that can't fail on most of the systems.

It is! Most systems have locale like pl_PL installed anyway, looking at the buildbots the majority do.

Even if the system has pl_PL installed, it's possible that it doesn't support %OB %Ob extensions. And we don't know for sure weather it supported or not.

Given this, how could we distinguish the wrong behaviour from the fallback route?
I mean, if we test for the standalone form, it's possible that the regular form is returned because of the fallback.
Hope it makes sense.

[encukou]

One trick would be to check for some common platform that does support %OB, for example:

if platform.libc_ver()[0] == 'glibc':
    "Polish month 2 MUST be 'luty'"
else:
    "Polish month 2 could be either 'luty' or 'lut'"

[serhiy-storchaka]

The test should check for example that calendar.standalone_month_name[5] is contained in the calendar output for May. It can also skip if calendar.standalone_month_name[5] == calendar.month_name[5].

[plashchynski]

I've added a new test test_standalone_month_name_and_abbr_pl_locale to verify the standalone month names and abbrs specifically in pl_PL. Please check.

[serhiy-storchaka]

LGTM. 👍

[encukou]

Thank you for seeing this through, @plashchynski!