On Sat, Aug 1, 2020 at 11:33 PM dn via Python-list <python-list@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@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@python.org <mailto:python-list@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 -- https://mail.python.org/mailman/listinfo/python-list
