> Replacing it would break backward compatibility. But adding a year function as an alias for calendar wouldn’t. And you could note in > the docs that year is preferred for new code, or even deprecate the old name over a few versions if it seems worth it.

> What about prcal (as opposed to pryear) vs. prmonth?

+1 on the idea of adding a `calendar.year()` alias, that would make sense. I don't think there would be a need to immediately deprecate `calendar.calendar()` though. If we did consider deprecating it at some point, the removal would have to be incredibly far out considering that it's been around for quite a while and is likely one of the most widely used functions in the calendar module.

Regarding `calendar.pryear()`, I think we should wait to see how widely used `calendar.year()` ends up being in comparison to `calendar.calendar()` before considering the addition of a second similar alias.

On Wed, Nov 27, 2019 at 10:02 PM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Nov 27, 2019, at 12:39, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
>
>
> In the calendar module, i find it terribly unintuitive to have a calendar.month but not a calendar.year, the default being calendar.calendar
>
> Suggestion: replace calendar.calendar by calendar.year

Replacing it would break backward compatibility. But adding a year function as an alias for calendar wouldn’t. And you could note in the docs that year is preferred for new code, or even deprecate the old name over a few versions if it seems worth it.

What about prcal (as opposed to pryear) vs. prmonth?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RFHTAKFOFOFDEWIMR2ZSVG74EII642MM/
Code of Conduct: http://python.org/psf/codeofconduct/