Daniel Quinn

Hi Tom, I'm just now getting around to this, but it's hard to make any changes without a test case. If you can provide an MT103 message that doesn't parse...

I'm not sure about this one. Is there somewhere in the spec that says it's ok to have newlines in these locations and not others? Your suggested changes are simple...

Alright I've had a conversation with some more financially-minded (as opposed to software like me) -people and it looks like line breaks are common in a message, so I'm going...

The easiest path that I could see for this would be to introduce `.available_objects()`, then add a deprecation warning to `.objects.all()`. Users could silence the messages by switching to `.available_objects()`...

More than that, opting for `.objects.with_trashed()` **breaks the default behaviour** which necessarily leads to instability in working with other components that expect those defaults. Even if it seems more intuitive...

I have a handy code snippet that I use these days to keep logging easy. Maybe this would help? ```python import logging class LogMixin(object): """ Use this mixin to do...

If you go with a sqlite store, you could extend this to include all of the main characters and fetch conversational fragments between them, or grab lines from just one...