[Lance E Sloan] > ... > (I think it's a little too bad that the timedelta class represents all > deltas as days and seconds.
And microseconds. > That must be why they don't support months, since months have > different lengths. IMHO...) That's right. It's hard to argue about what days, seconds and microseconds mean (note that I didn't say it's impossible <0.5 wink>). Exactly what "a month" means depends on who you ask, when you ask it, and what they're doing at the time. That is, there is no answer to the question that doesn't assume some policy that, while it may help some people some of the time, would at least as often get in the way for other people. datetime tries to be like, say, integers that way: a solid base with clear semantics, but if you want square roots you're gonna have to define what the heck you mean by that and do it yourself ;-) > Also, how can I make a copy of a datetime object? It's almost certainly the case that you don't really want to, but are suffering a confusion about something else that makes you _think_ you want to. It's hard to guess what that may be unless you can explain clearly what you think "making a copy" would _accomplish_ for you. It will almost certainly turn out to be the case that it would not accomplish what you're really after, or that there's no advantage in accomplishing it. datetime objects are (again like integers) immutable: there is nothing anyone can do to _change_ the value of a datetime object. In a nutshell, that's why "making a copy" is almost certainly irrelevant. For example, if you see that d.month is 7 at some point, d.month will always be 7 thereafter, no matter what other code you may run, just so long as `d` is bound to the same datetime object for the duration. There are no operations in the language that can mutate a datetime object's value. > timeA = datetime.now() > timeB = timeA # copy or reference to same object? Same object, and it makes no difference to that answer in Python no matter what appears on the right side of the first statement. You happened to use a datetime.date in this example, but it would be the same answer if you used an integer, string, list, tuple, function, bound method object, class, array, module, file ..., any object whatsoever. No exceptions. [Kent Johnson] > import copy > timeB = copy.copy(timeA) That does happen to make a distinct physical copy today, but there's no guarantee it will always do so. In general, _any_ operation is free to return a pre-existing instance of an object of an immutable type, if it has the correct value. Again there are no exceptions to that rule. Here's an example where copy.copy() doesn't happen to make a distinct physical copy today: >>> import copy >>> two = 2 >>> another_2 = copy.copy(2) >>> two is another_2 True Again, if anyone thinks "bad consequences" may follow from this, it's almost certainly the case that they misunderstand something else about Python. There is simply no way to tell whether two immutable objects with the same _value_ are or aren't the same physical object without looking at their memory addresses, and it's extremely rare for sane <wink> Python code to give a hoot about exactly where an object happens to reside in RAM. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
