Robin De Schepper

So a ... unit conversion package conversion package ... ;D On Tue, 6 Aug 2019, 13:58 Tony Hirst, wrote: > I was wondering about this too. > > The manipulation...

2. Then it would be nice if this internal functionality is accessible 3. That's for the fire-and-forget part, so that I can read out what the final schedule looks like...

There was 't much of a problem to begin with, I requested this to avoid spurious `.events` calls when operating on schedules and generators. Fine for me :)

2 cents: I prefer an explicit `.copy()` method on the objects themselves as well.

* `get` accepts a default argument that simplifies control flow: ```python val = labels.get("key", "(nil)") try: val = labels["key"] except KeyError: val = "(nil)" ``` * Same for `setdefault` *...

The purpose is to sanitize the input. The current interface doesn't allow me to read out results of operations on morphologies (does it?).

My user need here is to iterate over the tree and get all the 3d points out again that I had put in with a segment tree or by parsing...

It's for purposes outside of simulation and piggyback on arbor's parsers :) In this case it's non-soma/root centered morphologies.

Piggy-backing was written down that way for comedic effect. Often, always, people will nitpick for NEURON comparisons. Having read access to the data arbor concretely ends up simulating, is crucial...

Yes, one could piece together the flow from these logs, if it's available I'll PR a diagram to the docs ;)