questions re: calendar module

[dn]

On 02/08/2020 12:24, o1bigtenor wrote:
> On Sat, Aug 1, 2020 at 6:29 PM dn via Python-list
> <python-list at python.org> wrote:
>> On 01/08/2020 23:36, o1bigtenor wrote:
>>> On Sat, Aug 1, 2020 at 1:29 AM dn via Python-list
>>> <python-list at python.org <mailto:python-list at python.org>> wrote:
>>>      On 31/07/2020 02:52, o1bigtenor wrote:
>>>       > I regularly work in planning through multiple years at once.
...

>>> calendar starting
>>> from a date that is 3 years in time frame.
>> ...
>>
>>> I would like to show something like 2024 through the end of 2028.
...
> It is very disappointing - - - -suggests that thinking outside the space of
> one year is somehow deprecated. Frustrated when what you do demands
> that you think in longer periods of time (and yet have to function within
> the week as well).

I agree - says he who tactically changes his 'events calendar' every 
half-year, to ensure that there is more than a six-month planning 
horizon. Sister-in-Law has just this morning blocked-out dates for 
family gatherings ("you are expected to attend!") for not just 
Christmas/December, but into Jan, Feb, and Easter holidays (Uni 
vacation) next year; because U.David is but a mere-male and needs lots 
of 'extra help'...
(and because she knows 'the system', and has something similar at home!)


>> There are other helper functions. Also, we are invited to sub-class.
> 
> Hmmmmmm - - - will have to investigate that.

I'm thinking that the month function/method might be a better way to go 
(than year-at-a-time).

For visualisation (per next para), have you tried computing a month in 
the REPL and then str.split()-ting the output into separate week-strings?


>> Might it be possible to generate multiple year (or month) groups, split
>> them by line, and then reassemble line-by-line to produce the width and
>> temporal length required?
> 
> Likely work well if the months were considered as discrete blocks.
> Thinking that one could have something like
> 
>                 January 20xx                                  February 20xx
>        Su  Mo  Tu  We  Th  Fr  Sa             Su  Mo  Tu  We  Th  Fr  Sa
> 1                  1     2     3    4    5        5
>                   1    2
> 2     6     7    8     9    10  11  12       6     3     4    5     6
>     7   8    9
> 3    13   14  15   16   17  18  19       7    10   11  12   13   14  15  16
> 4    20   21  22   23   24  25  26       8
> 5    27   28  29   30   31
> 
> It is very useful for me to have the week numbers included. Have
> learned some fascinating things (some months have 6 weeks in
> them!) and the joys of formating (grin!).
>>
>> What do you think?

I'm no expert with the calendar module, having used it as many times as 
(probably only) once before!

However, skim-reading that page of the docs, I'd say that using the 
class to do the formatting is better than 'reinventing the wheel', and 
thus the question becomes: could the 'standard output' be post-processed 
into the form required?

The outline above (ignoring month/year and day headings) is basically:

weekNR <first line of output> gap weekNR <first line of output for next 
month> ...

as far across the page/screen as there is space/per the requirements.

Given that a <line of output> seems to be a fixed-length string, then 
you could indeed employ format() or f-strings with formatting.

The fact that some months have fewer, or more, weeks to include, is 
largely irrelevant. The solution is a standard "merge" algorithm. (us 
'silver surfers' cut our teeth on sorting, searching, and merging as the 
three pillars of "batch processing").

To print across the page/screen, we divide the available number of 
character-columns by the number of columns a single month's data 
requires (plus inter-month spacing) and this gives the maximum number of 
months the can be displayed 'across'.

Dividing that number into the number of months within the period, will 
give the number of month-rows required to 'do the job'.

A month-row could be defined as: 'as many lines as it takes to display 
every week of the month' (plus vertical separation/spacing).

So, now the challenge is to print each output line, combining 
(laterally) all of the relevant data/dates, in such a manner that after 
every so-many output lines, the visual-blocks representing each 
individual month's dates will become apparent.

The "merge" for line n (n:1-4~6) means to take the n-th <line of output> 
from each month in the current month-row and format them into a single 
o/p line. If a month does not have an n-th week, then substitute the 
requisite number of spaces (unless handled by f-string/format() 
"width"). Print the o/p line...
(yes, I omitted the weekNR-s, but adding them is trivial)


> I was starting from what I understood (how to print 'a' year) working
> to get closer to what I could use. Ncal allows me to display a
> calendar except I'm restricted to a display only 3 months wide. More
> than one month is relatively easy to display from present but not
> from some other point. It would seem that the 80 column display
> still rules supreme - - - - - and that's on a 1920 pixel wide monitor.

It may be possible by sub-classing, to override this limit - or to 
re-implement the applicable method. I haven't looked!
-- 
Regards =dn