<commit_before>
**New in 0.3.5: LESS IS MORE.** _The exception logger has been removed completely. It was fun to write, sure, but it was a lot of
code that wasn't ultimately related to django-signalqueue's core idea -- a remora on the streamlined body of the app;
a maintenance headache waiting to erupt; an awkwardly unedited metaphoric run-on slapped onto a technical summary; &c.
The new code will work fine if you're using a reasonably contemporary logging scheme, and it should behave properly even
if you're not; [post any issues](https://github.com/fish2000/django-signalqueue/issues) either way._

_If your apps were dependant any of the exception logger apparatus (models, views, the URL namespace, or the admin
panel), refrain from updating for the moment -- the next version will support [Sentry](github.com/dcramer/sentry) as well
as standard logging and will include a script to migrate your exception log data into a Sentry project instance. 
If you are concerned about this change, [post your issues now](https://github.com/fish2000/django-signalqueue/issues)
and I'll assuage your perdicament._

django-signalqueue
==================

After a certain amount of time anyone concerning themselves with the Django framework is going
to ask the question: *I love Django's signals, indeed. But if only I could dispatch them asynchronously.
Like, on some other thread or something, I don't really know.... Is that somehow possible?*<commit_msg>Nitpicks.<commit_after>**New in 0.3.5: LESS IS MORE.** _The exception logger has been removed completely. It was fun to write, sure, but it was a lot of
code that wasn't ultimately related to django-signalqueue's core idea -- a remora on the streamlined body of the app;
a maintenance headache waiting to erupt; an awkwardly unedited metaphoric run-on slapped onto a technical summary; &c.
The new code will work fine if you're using a reasonably contemporary logging scheme, and it should behave properly even
if you're not; [post any issues](https://github.com/fish2000/django-signalqueue/issues) either way._

_If your apps were dependant any of the exception logger apparatus (models, views, the URL namespace, or the admin
panel), refrain from updating for the moment -- the next push will contain support for logging exceptions thrown by
queued signals with [Sentry](github.com/dcramer/sentry) as well as standard logging, I'll include a script for migrating
exception log data to a Sentry project. If you are concerned about this change, [post your issues now](https://github.com/fish2000/django-signalqueue/issues)
and I'll assuage your perdicament._

django-signalqueue
==================

After a certain amount of time anyone concerning themselves with the Django framework is going
to ask the question: *I love Django's signals, indeed. But if only I could dispatch them asynchronously.
Like, on some other thread or something, I don't really know.... Is that somehow possible?*
{'fraction_non_alphanumeric': 0.07370923913043478, 'fraction_numerical': 0.007472826086956522, 'mean_word_length': 4.820158102766799, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2154981', 'n_tokens_mistral': 768, 'n_tokens_neox': 712, 'n_words': 416}