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

Reply via email to