Interesting, let me do the same example and see how my thought process differ.
I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design.
What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations.
Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program.
There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.
I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design.
What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations.
Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program.
There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.