TimeSeries.values or method addition

Looking at the usecase of tracing measurements of a process (e.g. production of paperclips over time) a user might be interested in values primarily in some cases (e.g. to compute the total amount of paperclips produced).

ts._d.values()
sum(ts._d.values())

I’d suggest to implement something similar to the following:

def values(self):
        """Return a list of all values in the time series (without time information)."""
        return self._d.values()

Wdyt? Are there other aspects to consider?

[johnhaire89]

Apologies for the tone of my previous comments, for answering without understanding what was being discussed, and for the thought bubble about pint =) I’m not sure if I’m adding anything beneficial to the thread, but I’m OK with the suggestion.

[ThomDietrich]

Hey @johnhaire89 I generally agree with you on most points. I disagree on units and that pint is the better alternative. I used pint before but it’s not comparable to what we are trying here. I think your approach to require a unit is one-sided. In the simple example from above, data points would not be samples of a continuous process. So instead of “5213 paperclips per hour” I would rather say “5213 paperclips since the last sample”. The problem is imho perfectly described by @nsteins in the proposal to implement a EventSeries.

Adding another view to this: @stringertheory suggested a new series class for this. Imho that’s a question of philosophy behind traces. Is an object purpose driven or universal? As a counter example: You might be familiar with InfluxDB measurements. Think of them as tables in a database specifically architected for time series data. A whole set of statistical functions can be used to query, slice, join, and aggregate data. InfluxDB does not concern itself with the nature of your datapoints and therefore whether the sum or integral functions are meaningful for your use case is really just up to you and your use case.

How do you guys feel about this different perspective?