On Tue, Feb 26, 2019 at 7:22 PM Terry Reedy <tjreedy@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.Barker@noaa.gov