[Tutor] Shifts and DateTime problems

mikalzet@libero.it mikalzet@libero.it
Thu, 7 Feb 2002 22:44:43 +0100 (CET)

On Wed, 6 Feb 2002, Kirby Urner wrote:

> You don't have to name your input arguments as long as they
> correspond,
> You may also choose to skip all those interim variables,

Thanks, yes of course ...

> If the only purpose of your class is really just to
> print something formatted, then you don't really
> need a class.  But I assume you're thinking to
> expand on the above model somehow.

Let's say that the final Shift class should have a method for adding a new
shift, reading a new shift ...and probably methods for calculating how
many hours are attributed to each different type of shift, how many to
each worker, to calculate how many hours of work are to be calculated as
night shifts and holiday shifts etc. etc.
In the end formatting and printing something might not even remain in the
shift class ! For the moment it is handy for learning how communication
between python and postgres works.
Then I think I'll need a Schedule class, capable of creating a new table
in my database for each month's or week's schedule and probably containing
the yet to be invented algorithm for automatically generating the shift
schedule while taking into account all the shifts to fill in, the hours
contracted for each worker, the various desiderata and just and lawful
impediments of each worker etc. etc. and probably a Worker class to handle
these aspects.
This already seems something way above my head ... but all this would have
to be handled in a Tkinter GUI ... and in the end have a method for
actually producing neat, legible ps or pdf or whatever printable files
which can be handed out to each worker and stuck on the notice board.

Now the thing I really haven't the faintest idea of yet is how different
classes could communicate with each other but I am content for the moment
with toddling along like this.

By the time I will have all this working Python version 7.0 will come out
and all the code written so far will have to be rewritten, of course !

> Finally, if DateTimeFrom is all you're using from
> mx.DateTime,

I think I'll know what I'll be using from mx.DateTime only at the end ...
if I ever come to one   :-))

Michele Alzetta