On Tue, Jan 12, 2016 at 11:53 AM, Bernardo Sulzbach <mafagafogiga...@gmail.com> wrote: > On Mon, Jan 11, 2016 at 9:45 PM, Travis Griggs <travisgri...@gmail.com> wrote: >> >>> On Jan 10, 2016, at 9:48 AM, Bernardo Sulzbach <mafagafogiga...@gmail.com> >>> wrote: >>> >>> Essentially, classes (as modules) are used mainly for organizational >>> purposes. >>> >>> Although you can solve any problem you would solve using classes >>> without classes, solutions to some big problems may be cheaper and >>> more feasible using classes. >> >> I think, this is often why, for a simple script, OO just kind of gets in the >> way. You have a straightforward procedure that you just want to do. The >> state (data) is not rich enough to make making it the focal point of your >> program. > > Your answer is quite good. I am not a purist myself (when it comes to > Java and C++, I am never going to instantiate a Math class to get a > logarithm function), but I understand the value of OO from experience. > As I mentioned those "tuples and dictionaries" to pass data around, I > would like to add that when a single script has two kinds of tuples or > dictionaries, you may be better of using two different classes, as > having "dedicated" types simplifies project organization and > enhances readability. >
Yeah. One thing I often recommend, especially to students, is to start with the very simplest and most naive code they can knock together, and then look at making it tidier afterwards. Classes, decorators, the unittest setUp/tearDown methods, and even functions themselves, are all just ways of improving code that could be written some other way. They're not rigid structures that you HAVE to comply with or your code is *just* *not* *good* *enough*. So start simplistic, and then look into it like this: "Hey, see how you're doing this five times? There HAS to be a better way!" (With acknowledgement to Raymond Hettinger.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
