[Tutor] Assistance request when using python 'calendar'

[Alan Gauld]

On 04/08/2020 22:39, o1bigtenor wrote:

> Very interesting, a program from the mid 1980's called 'cal' is far
> more flexible

But remember that cal is a user application. calendar us a
programmers building block. You can use calendar to create
an application but its not the final item.

> Sorry - - - - the assumption seems to be that this is an occasional
> kind of thing.

I'm not sure what you mean by that? Occasional in what sense?
As opposed to what?

> The solutions presented seem to infer that the request is somewhat static.
> If the entire code base needs to be rewritten each time the span of years
> desired changes then the tool is obstructing the work rather than assisting in
> that work's completion. So HTML isn't going to help much. Great idea for
> a static calendar but likely not as good for a flexible one.

You need to explain more about what you are trying to do. You certainly
shouldn't need to rewrite any code to accommodate changes to dates. And
HTML is just a presentation tool, it doesn't care too much what goes
into it.

> There are ideas present in said example but it might be easier to re-write
> perl code written by a now deceased mentor/friend where that code got most
> of the job done but there are some things that need changing and a few bits
> of the visuals I desire to change.

One of the great things about software is that if the building blocks at
hand don't do what you want you can always drop down a level to the more
primitive blocks and build exactly what you do want.

> I have been looking for about 4 years for software usable 

You could have written  a lot of code to do exactly what you
wanted in 4 years.

> My research has shown that week numbers is something that is actually
> quite a foreign concept in many cultures as this just isn't the way things
> are done. Except - - - - - if I give you a date and ask you for the date
> some 45 days before and 105 days after - - - - well that's another program

Yes, and another module in Pythons case. That's what datetime is for.
Calendar is quite a limited module designed for a fairly specific task.
If you need more datetime is probably a better option, but you need to
do the output formatting yourself.

> take a week number and subtract 6 (and three days please) and add
> 15 to the week number. No programming and very very simple steps.

We are discussing programming modules so you are unlikely to get a
solution with "no programming" but you will find the tools such that
you can program it such that you users don't need to.

> There are LOTS of calendars like that out there. They mostly all have one
> huge limitation - - - - they work within one (1) year - - - 

Which tells us that the vast majority of programmers never need to go
beyond that. Certainly in 30+ years writing business level applications
I never had a need for any calendar display beyond 1 year. The app could
handle multiple different years but display was always limited to 1
year. The fact that most modules support that suggests I am not alone.
So if you need something different you probably need to write it
yourself. All modules are created to meet someone's need. If your need
exceeds what the module can do you will need to do the extra work
yourself. And hopefully then make it available to others as a module.

>> C-language extension), so you can readily study it to work out potential
>> subclassing. In particular, you may wish to study the .formatyear() methods
>> of the text and HTML classes.
> 
> I have spent some time looking for 'official' Python information on sub-classes
> and their development. Found nothing to date but have only spent some 45
> minutes so maybe with more time some to be found - - - maybe.

I don't know where you were looking because the official Python
tutorial includes that(Sect 9.5), as does almost every other
tutorial - including mine(see .sig). The technique is identical
to almost every other OOP language.

> Much work to be done and it is ever so fascinating to see how prevalent
> business thinking is confined into small time frames. But then business is
> primarily worried about profitability per quarter - - - - - well that
> is what the
> senior staff earn their bonuses on - - - - but here - - -  I really do need to
> work across at least 3 and preferably even 5 years but that's considered
> to be a corner case - - - - .

Breaking new ground is always interesting. But also laborious.
I remember the first time I had to write an app that worked in
local time in sites all round the planet while keeping synchronised
to a central time. I naively thought there were 24 time timezones
neatly separated by hours, easy. Then discovered there were around
40 arranged in near random patterns with different daylight saving
arrangements etc etc. And none of the OS or databases at the time
supported any of it, we had to code it from scratch. When you go
beyond the norm it is always difficult.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos