questions re: calendar module

[o1bigtenor]

On Sat, Aug 1, 2020 at 11:33 PM dn via Python-list
<python-list at python.org> wrote:
>
> 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!)
>

(LOL) something like that except what I'm working with also needs the
to the day planning as well as the long term stuff. Did some 'counting'
here. there are from 8 to 14 discrete event times for a group within a
'period' (presently a year but that may change) and there are multiple
groups. The event timing (spacing) is mostly similar. There is also a
need for multi-event (think year) planning as well.
I could see a busy theater organisation doing a similar kind of planning.
>
> >> 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").

The differences become very relevant for formatting. A month that has
4 weeks takes a different amount of vertical space than a month that
has 6 weeks.
>
> 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!

Interesting ideas - - - - time for more digging!

Thanks