Are the critiques in "All the things I hate about Python" valid?

[Richard Damon]

On 2/20/18 3:51 PM, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
> <rantingrickjohnson at gmail.com> wrote:
>> On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
>>
>>> The point he was making is that if you store a person's age, you'd have
>>> to update it every year. It's far better to store the date of birth and
>>> calculate the age on demand.
>> *AHEM*
>>
>> At the risk of being labeled a "quibbler" (which, in the
>> grander scheme is not really all that bad considering some
>> of the names that have been attributed to me), i must say
>> your advice is only "sound advice" in cases where the age
>> will not be queried frequently.
>>
>> For instance, if the age is queried many times a second, it
>> would be a much wiser design to set-up an event that will
>> advance the age at the end of the last second of every year,
>> instead of doing the age calculation many times a second.
>> Heck, even if the frequency is multiple time a day, a valid
>> argument could be made.
> Nope. Even if you need the age many times per second, it's still
> better to store the date of birth, because you eliminate boundary
> conditions and duplicated data. But that's assuming you're storing the
> age of *a person*. If the age in question is a boundary ("motor
> insurance premiums are increased if the driver is 65 years or older"),
> then it's still sane to store the age.
>
> ChrisA

I would normally expect that the persistent store would have a birth 
date of the person, but within a local operation, you likely want to be 
able to assume the consistency of a attribute like over 55 years old, so 
you would compute the age, for that operation, but not keep it beyond 
that. Otherwise, depending on the order of doing your checks you may 
find that during your processing they are either both or neither of 
under 55 and over 55. It is much easier to reason that your code is 
correct when you can prevent (and thus ignore) such data races. This 
normally means your operation grabs the value of 'now' once, and all 
processing will be based on THAT point of time, not what currently is 
'now'. How big this 'timestop' needs to be depends on how wide the 
requirement is for temporal consistency. It might be just within a 
function, it might be for the full duration of the program run, 'now' 
might even be a parameter to the program, i.e. as of last (or next) 
midnight, do the computation.

-- 
Richard Damon