Better log interface

[dmitriy-serdyuk]

Currently log is represented as a defaultdict and the interface is always assuming that it is a defaultdict which makes a bit hard to implement new backends. I had some troubles mimicking this interface when I was implementing jsonlines-based log #1013. So it would be great to restrict the interface a bit and make it more explicit to allow more complicated backends.

In particular, I'd like to see in the interface:

• Log should be always included in a context manager to (de)allocate resources properly
• Separate read+write and read-only regimes
• A standard way to tell that a new iteration has started
• It should be a way to tell what is the number of past entries accessible to read/change
• Discourage modification of rows other than the current row and the previous row

(It is mostly for myself, to arrange my thoughts, I'm happy to hear your suggestions)

[dwf]

Is there a case to be made for allowing modification of rows other than the
current row?

On Mon, Jul 11, 2016, 4:46 PM dmitriy-serdyuk notifications@github.com
wrote:

Currently log is represented as a defaultdict and the interface is always
assuming that it is a defaultdict which makes a bit hard to implement new
backends. I had some troubles mimicking this interface when I was
implementing jsonlines-based log #1013
#1013. So it would be great to
restrict the interface a bit and make it more explicit to allow more
complicated backends.

In particular, I'd like to see in the interface:

• Log should be always included in a context manager to (de)allocate
  resources properly
• Separate read+write and read-only regimes
• A standard way to tell that a new iteration has started
• It should be a way to tell what is the number of past entries
  accessible to read/change

(It is mostly for myself, to arrange my thoughts, I'm happy to hear your
suggestions)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1129, or mute the thread
https://github.com/notifications/unsubscribe/AADrLkL1IH41vqyjBcRdSW0izrFGS_2cks5qUqu2gaJpZM4JJw9_
.

[dmitriy-serdyuk]

Good point. And maybe the previous row should be writable.

[dwf]

We could actually enforce this using this. It's a one-file dependency we can bundle in utils.

We can make it such that entries for a given step in the log dict are always mappingproxy objects that wrap a dict that is accessible for mutation when it is accessed by log.current_row or log.previous_row, and immutable otherwise.