No longer maintained?

[nielsuit227]

This repo looks like it's no longer maintained, with the last PR merged over two years ago.
Are you looking for active maintainers? What's the plan for this repo?

[RGD2]

Author is probably just busy with life. (further general disc.)

Temporary Workaround in ipython / jupyter is switch to a fork for now:
BTW this works for any pip package, you're welcome!

# Fix for 'duration is an unknown type' when trying to plot.
# official pip repo not updating as of 2023, last update 2020.
# remember to restart your python kernel!
!pip uninstall traces
!pip install git+https://github.com/zzrcxb/traces

BTW this works for any other pip package in a git repo, which might even be your own.
You're welcome!

[LucaCerina]

My guess is that datascopeanalytics has been acquired (at least that what I got looking around the internet) and now this project it's either a dead project or some internal package.

I use it extensively for another project of mine, and there are some things to iron out. I am honestly considering forking to some 'traces2' project, but currently don't have the time to do that.
I will keep you posted if there are updates on this

[stringertheory]

I haven't been maintaining this for years! But recently I've been kind of feeling like getting back into it.

I was thinking I'd start with some basics:

• updating the CI, making sure tests pass in more recent python versions, etc.
• go through issues and fix bugs
• maybe add EventSeries (a la TimeSeries.values or method addition #227 and Event Based Time Series #229)

@LucaCerina would be curious to hear about what needs ironing out!

[LucaCerina]

Hi @stringertheory, glad to see you back.

One of the things that led me to some long debug sessions is also one of the pros of the library. The versatility of keys and values. It happened in various occasions that unexpected None values (coming from operations between TimeSeries, sampling undefined timestamps etc) led to some type-dependent bugs.

In the same way the merge of two timeseries with different value types is allowed (e.g., float and strings) and that creates a TimeSeries where some logical/numeric operations may work on some values but not on others.
In the draft of a library I have started a couple of weeks ago I have sacrificed a bit these capabilities for a "typed" key/value implementation, so that some checks and warnings are thrown in case of ambiguous operations (sums, interpolations, etc..).

There are also some design choices in terms of what is considered an error and what not. For example remove raises KeyErrors, but remove_points_from_interval does not. The barebone documentation of the code sometimes does not help with understanding your choices.

Last, but this is more syntax sugar than a real issue, the TimeSeries class is essentially a SortedDict with added functions, so I thought it would be better to just subclass SortedDict and inherit many of its functions (keys, items, set/get item, len etc...)
From that we get a proliferation of get functions that could be merged in a single __getitem__ function, while others are missing (e.g., often I just need the values of the TimeSeries, but there is no values function).

The initial draft of a new library is currently in a private repo, with the basic functions implemented (get/set/iter, interpolation, resampling and compact) but missing operations, distribution and plotting. Happy to discuss it more in detail.

P.S. This is the library https://github.com/LucaCerina/physio-cassette that currently employs traces for some functionalities, specifically the EventRecord class.

[stringertheory]

Thanks @LucaCerina, this is helpful!

Makes sense about the type-related issues. That was something the team that worked with this early on discussed a lot, and we landed on the principles of "be more like a built-in dict than a numpy array" kind of approach to types. But if there were some stronger assumptions about type, there could also be some helpful additional methods.

And 100% agree that documentation is (very) lacking, and that the consistency of the API can be improved. That seems like the top priority to me, coming back into with somewhat fresh eyes.

Also there was some reason that we ended up not subclassing SortedDict, but I can't remember it now! Maybe time to revisit.

And thanks for the link to physio-cassette. I will take a look at it!