Would allow filters to be and'ed/or'ed.
Using syntax like this:

handler = MessageHandler((Filters.text | Filters.venue) & Filters.forwarded, callback)

Currently this isn't too useful since the only filter that can be and'ed to any other is forwarded, but that should all change with #409.

The code currently requires all filters to be created as a class and then initiated before they can be used, which could be an inconvenience to the user if they want to create their own filters. To remedy this we could add a decorator like this:

def Filter(f):
    def wrapper(self, message):
        return f(message)
    return type(f.__name__, (BaseFilter,), {'__call__': wrapper})()

That would allow users (and us) to make filters like this:

@Filter
def Text(self, message):
    return bool(message.text and not message.text.startswith('/'))

The reason I didn't immediately go with this, is that it might be confusing if someone (especially someone new to python) reading the code stumbles upon a dynamic class creator.
Thoughts?

• Figure out implementation
• Write the code
• Write the docs
• Add snippet to wiki
• Wait for Add entities filter #409 to get merged?

Edit: After talking in dev group, the decorator has been declared too gross to look at :P