[issue28253] calendar.prcal(9999) output has a problem

Change by Serhiy Storchaka : -- pull_requests: -982 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue28253] calendar.prcal(9999) output has a problem

Changes by Donald Stufft : -- pull_requests: +982 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue28253] calendar.prcal(9999) output has a problem

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed superseder: -> Make Calendar.itermonthdates() behave consistently in edge cases ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Roundup Robot added the comment: New changeset f2aff898f7c8 by Alexander Belopolsky in branch '2.7': Issue #28253: Fixed calendar functions for extreme months: 0001-01 and -12. https://hg.python.org/cpython/rev/f2aff898f7c8 -- ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Roundup Robot added the comment: New changeset 7efba48299e9 by Alexander Belopolsky in branch 'default': Issue #28253: Added a NEWS entry. https://hg.python.org/cpython/rev/7efba48299e9 New changeset 55f11196c949 by Alexander Belopolsky in branch '3.5': Issue #28253: Added a NEWS entry. https://

[issue28253] calendar.prcal(9999) output has a problem

Roundup Robot added the comment: New changeset c439bce36bf2 by Alexander Belopolsky in branch '3.5': Issue #28253: Fixed calendar functions for extreme months: 0001-01 and -12. https://hg.python.org/cpython/rev/c439bce36bf2 New changeset cd384c4b441a by Alexander Belopolsky in branch '3.6':

[issue28253] calendar.prcal(9999) output has a problem

Changes by Serhiy Storchaka : -- assignee: serhiy.storchaka -> belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: The patch LGTM. You can see how itermonthdates() is used in third-party code: https://github.com/sunlightlabs/django-locksmith/blob/master/locksmith/hub/dataviews.py https://github.com/quandyfactory/Quandy/blob/master/quandy.py https://github.com/takanory/plo

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: issue28253-4.diff should be good now. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue28253] calendar.prcal(9999) output has a problem

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file44837/issue28253-4.diff ___ Python tracker ___ ___ Python-bugs-list

[issue28253] calendar.prcal(9999) output has a problem

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file44845/issue28253-4.diff ___ Python tracker ___ ___ Python-bugs-list m

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: Something went wrong with issue28253-4.diff. I'll investigate and replace. -- ___ Python tracker ___

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: > The patch LGTM except tests. What are your issues with the tests? Did you see the -4 patch? > But we should at least document the behavior of itermonthdates(), > monthdatescalendar() and yeardatescalendar() at corner cases. I would rather not. At lea

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: The patch LGTM except tests. But we should at least document the behavior of itermonthdates(), monthdatescalendar() and yeardatescalendar() at corner cases. -- ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Xiang Zhang added the comment: Patch LGTM. > I would rather not mess up with itermonthdates(), particularly in a bugfix > release. We can postpone the discussion of a better way to handle date > over/underflow in itermonthdates() until 3.7. Before finally find a better way, can we at least

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: issue28253-4.diff is issue28253-3.diff with tests. -- Added file: http://bugs.python.org/file44837/issue28253-4.diff ___ Python tracker __

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: issue28253-3.diff uses itertools.repeat(). -- Added file: http://bugs.python.org/file44836/issue28253-3.diff ___ Python tracker ___ __

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: issue28253-2.diff is a small performance improvement over issue28253.diff -- Added file: http://bugs.python.org/file44835/issue28253-2.diff ___ Python tracker ___

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: > unless we remove all date limits that is much harder issue I don't think this is too hard. I think the original implementation did not have date limits. I've opened a separate issue for this. See #28281. -- _

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: I am attaching the proposed reimplementation of itermonthdays2() and itermonthdays(). It does not use itermonthdates() and is not that complicated. It passes test_calendar, but I did not test it further than that. I would rather not mess up with itermo

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: Yes, the current documentation is an impossibility (unless we remove all date limits that is much harder issue). Raisin OverflowError will make the implementation of itermonthdays2() and itermonthdays() more complex. Yielding dummy instances or None requires

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: > itermonthdates() is documented public method The current documentation is an impossibility: "The iterator will yield datetime.date values and will always iterate through complete weeks, so it will yield dates outside the specified month." The current

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: Note that the stop on date.max behavior was introduced in #15421. -- ___ Python tracker ___ __

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: itermonthdates() is documented public method. We should do something with it. Maybe emitting dummy data instances is the simplest way to solve this issue. -- ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: On the second thought, I don't see why itermonthdays2() and itermonthdays() need to use itermonthdates() at all. It looks like it is easy to implement those using monthrange() and some simple integer arithmetics. --

[issue28253] calendar.prcal(9999) output has a problem

Alexander Belopolsky added the comment: I would leave itermonthdates() alone and just fix itermonthdays2() (and itermonthdays() for consistency) as Xiang suggested. The fix can be implemented by breaking on date.month != month and adding something like for wd in range(date.weekday(), 7):

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: The problem with year 1 was reported in issue26650. -- ___ Python tracker ___ ___ Python-bugs-list

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: Having additional tests is always nice. After writing tests we can search whether there is other solution. AFAIK the dummy data needs also the day attribute. -- ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Xiang Zhang added the comment: How about the approach in calendar_prcal__demo.patch? If it's not bad I can add tests then. -- Added file: http://bugs.python.org/file44793/calendar_prcal__demo.patch ___ Python tracker

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: This is not just not elegant, but it doesn't work if firstweekday is not 0. The lowest level in the calendar module is itermonthdates(). But the problem is that dates outside supported range can't be represented. While the output for December of the year 999

[issue28253] calendar.prcal(9999) output has a problem

Xiang Zhang added the comment: Something like this? diff -r 15f82b64eee0 Lib/calendar.py --- a/Lib/calendar.py Thu Sep 22 17:11:53 2016 -0700 +++ b/Lib/calendar.py Fri Sep 23 16:27:03 2016 +0800 @@ -181,6 +181,9 @@ yield (0, date.weekday()) else:

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: Html calendar formats the last week differently for years 9982 and . Year 9982: 2728293031   Year : 2728293031 I think this issue should be fixed on lower level than text calendar formatter. -- ___ Python

[issue28253] calendar.prcal(9999) output has a problem

Changes by Xiang Zhang : -- keywords: +patch Added file: http://bugs.python.org/file44789/calendar_pryear_.patch ___ Python tracker ___ __

[issue28253] calendar.prcal(9999) output has a problem

Xiang Zhang added the comment: calendar internally relies on datetime and uses datetime.date. datetime.date can't represent date more than .12.31 so some logic is broken for it(normally the week list should be of length 7, date outside the month will be (0, x) pair but this is not the case

[issue28253] calendar.prcal(9999) output has a problem

Serhiy Storchaka added the comment: Thank you for your report lijp. This is interesting issue. It is not specific for Windows. itermonthdates() yields shortened sequence of dates at the end of maximal year. The formatted row of day numbers is centered. Since the number of days is less than ex

[issue28253] calendar.prcal(9999) output has a problem

Changes by lijp : Added file: http://bugs.python.org/file44788/20160923154147.png ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue28253] calendar.prcal(9999) output has a problem

Changes by lijp : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: the reply's additional "Re:" -> calendar.prcal() output has a problem type: -> behavior versions: +Python 3.4 ___ Python tracker