Am 11.09.17 um 16:12 schrieb Paul Moore:
Thanks for the information. That's more or less the sort of thing I
was thinking of. In fact, from a bit more browsing, I found another
way of approaching the problem - rather than using pygame, it turns
out to be pretty easy to do this in tkinter.
That is good advice. Actually, I was going to suggest to look into GUI
frameworks to understand OO and classes. GUI is one of the topics where
OO really fits well and has practical applications.
For example, derive from an entry widget to implement a greyish "hint"
value which vanishes when you type in something new. That thing is a
class and there can be more than one of it in program, there you have
instances. Or an entry which does autocompletion on a list of predefined
values when you hit tab or enter. Useful, and obviously you need
different instances for different input fields, hence objects.
In some other more statically compiled languages, OO is shoehorned into
everything ("abstract factory" and that stuff), because virtual calls
are the only way to get dynamic behaviour / late binding. In Python you
use OO only in places where it really makes sense.
Christian
--
https://mail.python.org/mailman/listinfo/python-list