questions re: calendar module
dn
PythonList at DancesWithMice.info
Sun Aug 2 00:31:22 EDT 2020
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
More information about the Python-list
mailing list