Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

I have made the requested changes; please review again
and I have kept

# Constants for months referenced later
January = 1
February = 2

as it is

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

I have made the requested changes; please review again

Thanks for making the requested changes!

@ethanfurman: please review the changes made to this pull request.

what should I do?

If you think test cases are necessary, add what you expect users to do.
eg.

for m in Month:
    calendar.weekday(2021, m, 2) == calendar.weekday(2021, m.value, 2)

though I think this change is okay with no test case.

though I think this change is okay with no test case.

Yes, if you want i can change the return type of function returning 0-6 for days to enum , if not then i guess this is okay without test.

Hi @sunmy2019 , @hugovk
should we raise a deprecation warning for January, February

deprecated_names = ['January','February']

def __getattr__(name):
    print(name)
    if name in deprecated_names:
        warnings.warn(f"{name} is deprecated", DeprecationWarning)
    return name  

I picked the code from https://peps.python.org/pep-0562/

why name is picking __path__?

Hi @sunmy2019 , @hugovk should we raise a deprecation warning for January, February

The question is, are we gonna deprecate these two names.

My opinion:

I think it's better to directly remove January and February since they weren't in __all__ before. They are never in the public API.

We don't need to provide compatibility over non-public names unless it is widely used by others. No one should use these names since only 2 of the 12 months exist.

But since @ethanfurman requested "as-is". I would interpret it as "Do not change these things, and we are not going to deprecate them for compatibility".

But since @ethanfurman requested "as-is". I would interpret it as "Do not change these things, and we are not going to deprecate them for compatibility".

okay, sure

Btw, I got it why doesn't it works in Python 3.12, __getattr__ is not getting called for module-level attributes

The "DO-NOT-MERGE / unresolved review" check is there to denote outstanding red code review.

But since @ethanfurman requested "as-is". I would interpret it as "Do not change these things, and we are not going to deprecate them for compatibility".

My apologies, that was a misunderstanding -- I meant the initial change was fine as-is (in other words, no need to make the same change as above by iterating directly over Month).

Please put that change back in place, and remove the January and February constants.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again

I guess the below error is not related to the change

D:\a\1\s\Modules\_tkinter.c(53,10): fatal  error C1083: Cannot open include file: 'tcl.h': No such file or directory [D:\a\1\s\PCbuild\_tkinter.vcxproj]
D:\a\1\s\Modules\tkappinit.c(16,10): fatal  error C1083: Cannot open include file: 'tcl.h': No such file or directory [D:\a\1\s\PCbuild\_tkinter.vcxproj]
    0 Warning(s)
    75 Error(s)

Time Elapsed 00:04:34.47
##[error]Cmd.exe exited with code '1'.
Finishing: Build CPython

Thanks for making the requested changes!

@ethanfurman: please review the changes made to this pull request.

Thanks @ethanfurman, I can create a new PR for the same