Don't get me wrong, I live in python, I create classes on the odd occasion I need them and not before it's definitely required.
That said, there's nothing wrong with sitting down and modelling the problem you're trying to solve on paper to try to understand what's involved. You don't need to implement it that way. Whatever you do, stop and take a moment to think it through.
You don't literally have to start with one function. If you've solved a similar problem before you may have a good idea of what the code structure is going to be (this is what design patterns are all about). Frameworks may force a structure on you. There are shortcuts. But even then, I've been bitten more then once by the problems that looked awfully similar to what I've done before only to turn out to be very different at the end.
>>> DataType = namedtuple("DataType", ["field1", "field2"])
>>> datum = DataType(1, "a")
>>> datum
DataType(field1=1, field2='a')
>>> datum.field1
1
>>> datum.field2
2
[1]: http://docs.python.org/2/library/collections.html#collection...
DataType = union({ 'type1': ['field1', 'field2'], 'type2': ['field3'] })
DataType.type1(val1, val2)
DataType.type2(val3)
# pretend syntax
case datum:
DataType.type1(a, b):
doSomethingWith(a, b)
DataType.type2(c):
doSomethingWith(c)On another note, the problem with the way OO, and really programming in general at the uni level, is taught is that it's always in the context of toy apps that aren't going to grow. This encourages an up front planning process and you can get away with it because all you have to do is make it work. You're only learning how to tell the computer what to do, not how to build a system that can adapt to a changing user base for instance. Perhaps it's necessary that you learn to just talk to a computer first and with experience learn to build growable systems. The problem though is that the upfront planning process is taught as _the_ way to build a system.