On Tue, Feb 26, 2019 at 7:22 PM Terry Reedy <tjre...@udel.edu> wrote:
> > timedelta.total_seconds()
>
> To me, total_x implies that there is a summation of multiple timedeltas,
> and there is not. So not intuitive to me.
THAT was a discussion for when it was added -- I can't say it's my favorite
name either. But at least a quick glance at the docstring will address
that. Hmm -- that one could use a little enhancement, too:
In [3]: td.total_seconds?
Docstring: Total seconds in the duration.
But at least it COULD be made clear in a docstring :-)
> (Neither us current obscure
> option). It is also not obvious is answer is rounded to nearest second
> or not.
>
also could be made clear in a docstring -- the full docs say:
"""
timedelta.total_seconds()
Return the total number of seconds contained in the duration. Equivalent to
td / timedelta(seconds=1).
Note that for very large time intervals (greater than 270 years on most
platforms) this method will lose microsecond accuracy.
"""
That last point indicates that it is not rounded -- and a quick check will
note that it returns a float -- but those docs could be improved to make it
clear that a float is returned. (i.e. that is WHY it loses microsecond
accuracy). But anyway, you are nevert going to know all the intricacies of
a method by its name -- you need to know about the rounding and all if you
are trying to decide if you are going to us the method, but if you read it,
you probably have a pretty good idea what it does.
Anyway -- "I don't really like the name much" is really the answer to a
different question
(I don't like it either, but it's what's there)
> So at most, we could have:
> >
> > .total_microseconds()
> > .total_seconds()
> > .total_minutes()
> > .total_hours()
> > .total_days()
> > .total_weeks()
>
> I am also not enthusiastic about multiple methods doing essentially the
> same thing. I might prefer one method, .convert? with an argument
> specifying the conversion unit, 'microseconds', 'seconds', ... .
yup -- that's been proposed, and is still on the table as far as I'm
concerned.
Though I'm not sure I like "convert", but would rather, say "in_unit" or
"to_unit". But any of these would address the intuitive and discoverability
issue -- very few folks would have any trouble guessing what any of:
a_datetime.convert("hours")
a_datetime.to_unit("hours")
a_datetime.total_hours()
mean -- at least generally, even if they con't know if they are getting a
float or an integer result.
And as for discoverable, any of these as methods on a dt object would
probably be checked out if you were looking for such a thing.
> I think this is in python-ideas territory.
>
I'd rather not :-) -- have you SEEN the length of the thread on how long
the line limiet should be in PEP8.
Frankly, I think the arguments have been made, and the options on the table
-- if this were a PEP, it would be time for a pronouncement -- or at least
one of:
- not going to happen
or
- maybe happen but we need to iron out the details
I've lost track of where we are with the governance model, so is there a
way to get a clear idea for whether it's time to drop this?
BTW, I don't think this is worth a PEP, but if I get a go-ahead, and it
needs to be written up, I'd be willing to do so.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
