CherryPy Server has Awful Documentation

Just an observation. If I ever figure out how to do what I want with it I will have to write some introductory material because it is a shame a project as stable as CherryPy is so completely unapproachable. I am trying to have CherryPy serve a non-CherryPy WSGI app, as well as serve static files. (The WSGI app in question is a Django app.) I'll write a longer post if I ever crack this puzzle.

TastyPie's Validation.is_valid: a case of careless naming

TastyPie is a utility to add RESTful APIs to your Django app. TastyPie abstracts some of the more mechanical aspects of REST API implementation and provides high-level interfaces that make it easy to get up and running.

One of the hooks provided by TastyPie is validation. It provides its own Validation class for you to subclass if you need to execute some custom validation logic. All your logic goes in an is_valid() method. This method returns a dictionary of error messages. If there are no validation errors, an empty dictionary gets returned, signalling that all is well.

...wait, what? So this is how it works, ideally:

>>> my_validator.is_valid('good data')
{}
>>> bool(my_validator.is_valid('good_data'))
False
>>> my_validator.is_valid('bad data')
{'__all__': 'Bad input'}
>>> bool(my_validator.is_valid('bad data'))
True

Does this prevent TastyPie from achieving its goal? No. But was this name poorly chosen? I think so. Small mental mixups like this add up fast. And especially in a language like Python, where the emphasis is on concise, easy-to-read code, it seems like quite a blunder. Frameworks should be used when they simplify and enhance development, so the names should be well-chosen and meaningful.