As Mike says, you can’t avoid PyMongo – all the other interfaces build on top of it. These other interfaces are arguably unnecessary. ORMs such as that used in Django are useful when dealing with SQL because they mitigate the complexity of creating SQL queries and schemas, and parsing result sets into objects.
PyMongo however already has that covered – queries go through a convenient and simple API and results coming from MongoDB already are objects (well, dicts in Python – same difference) by definition. If you feel that you really need to decorate your Mongo documents with Python objects, it’s easy to add a SON manipulator to PyMongo. The nice thing about this approach is that you can write code directly on PyMongo, and slide in additional functionality later on without having to insert a new API between your code and PyMongo.
What’s left? Schema creation and migration are somewhat useful, but are almost as simply done ad-hoc – chances are if you’re considering using MongoDB you want to break out of the traditional SQL-style model anyway. Also, if there were a fully Django-compatible MongoDB ORM you might get some mileage out of it. Anything less than that and you will probably be creating work for yourself.
You won’t regret using PyMongo directly.
One last option worth watching if you are interested in top efficiency is the asynchronous version of PyMongo, here: http://github.com/fiorix/mongo-async-python-driver