Why use a feed reader library?
Have you been unhappy with existing feed readers and wanted to make your own, but:
never knew where to start?
it seemed like too much work?
you don’t like writing backend code?
Are you already working with feedparser, but:
want an easier way to store, filter, sort and search feeds and entries?
want to get back type-annotated objects instead of dicts?
want to restrict or deny file-system access?
want to change the way feeds are retrieved by using the more familiar requests library?
want to also support JSON Feed?
want to support custom information sources?
… while still supporting all the feed types feedparser does?
If you answered yes to any of the above, reader can help.
The reader philosophy
reader is a library
reader is for the long term
reader is extensible
reader is stable (within reason)
reader is simple to use; API matters
reader features work well together
reader is tested
reader is documented
reader has minimal dependencies
Why make your own feed reader?
So you can:
have full control over your data
control what features it has or doesn’t have
decide how much you pay for it
make sure it doesn’t get closed while you’re still using it
really, it’s easier than you think
Obviously, this may not be your cup of tea, but if it is, reader can help.
Why make a feed reader library?
I wanted a feed reader that is:
accessible from multiple devices
with a simple UI
self-hosted (for privacy reasons)
modular / easy to extend (so I can change stuff I don’t like)
written in Python (see above)
The fact that I couldn’t find one extensible enough bugged me so much that I decided to make my own; a few years later, I ended up with what I would’ve liked to use when I first started.