New submission from Şahin :
import calendar
calendar.nextmonth(2018, 11) returns (2018, 12) which is OK.
calendar.nextmonth(2018, 12) returns (2019, 1) which is also OK.
calendar.nextmonth(2018, 13) returns (2018, 14). It would make more sense if
this was raise calendar.IllegalMonthError
Change by Şahin :
--
keywords: +patch
pull_requests: +10128
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35406>
___
___
Python-
Şahin added the comment:
I understand you but i still think these functions need to check it. As an
end-user, I shouldn't see these functions to work with no errors for illegal
months.
--
___
Python tracker
<https://bugs.python.org/is
Şahin added the comment:
I'm suggesting this idea to consistency. Why an IllegalMonthError exists in
calendar module if we don't raise this error when required?
What would you say if I asked you to "What is the month number coming after
156th month?" Would you say 157 or
Şahin added the comment:
OK now it isn't a problem if we shouldn't use this function directly but how am
i going to understand if a function is public API or not? In classes, we are
using single or double underscore to indicate that the function or variable
we're declaring is
Şahin added the comment:
OK, thank you all for information. It's now clear for me too why this is not an
issue. I'll try to close this issue by selecting status as close but if it
isn't working with this way (I'm new, I don't know how) anyone can close this.
-
Şahin Kureta added the comment:
I know it is not finalized and released yet but are you going to implement
Version 14.0.0 of the Unicode Standard? It finally solves the issue of Turkish
lower/upper case 'I' and 'i'.
[Here is the
document](https://www.unicode.org/Public/