Why reader?

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

• fast

• 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.