On Wed, 4 May 2022 at 01:06, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Extrapolating this particular suggested change from one example seems dangerous. Particularly since much of this is
limitedto the case of treating a timestamp as both a timestamp and date at the same time. Making any change from what
isseemingly a rare corner-case doesn't seem to provide a sufficient benefit/cost ratio.
>
> I have to put this into the "unfortunate foot-gun" category at this point. Users should be testing their code. I'm
surethere are other concerns given the layer of indirection, but a general rule to "always cast your parameters" goes a
longway if one chooses to avoid the API where explicit parameter types can be supplied. Or at least "cast once, cast
always"for any given parameter.
Yes, this was admittedly a contrived case, not only for the use of ts,
but also because ts was passed as a string rather than a Python
datetime, which would have resulted in the parameter oid specified.
So, many layers of good practices weren't followed in the first
place... making me think that specifying such a corner case in the
documentation would have limited utility (a rare occurrence mostly
encountered if someone doesn't read the docs).
-- Daniele