Recommendation for python form validation library [closed]

Question

I would like a form validation library that

1.separate html generation from form validation;

2.validation errors can be easily serialized, eg. dumped as a json object

What form validation library would you choose in a python web project?

Answer 1

Disclaimer

Generally speaking I'm a little wary about HTML form libraries now. If you use something from a mega-framework, you invariably have to bring in the whole mega-framework as your dependency.

Many sub-components of many mega-frameworks claim to not depend on the framework but let's not kid ourselves. If you don't use one, there are at least a dozen form libraries that I know of out there with a wide range of differences in capabilities. Just the choices alone can get quite confusing. Generally speaking, as Ian Bicking says many years ago and is still true, I think the notion of one form library that suits everybody is quite ludicrous. In fact I'd argue you probably need to think twice before deciding you really need one. Chances are mostly of the time you just need a form validation library like FormEncode. It really depends on how you want to use it.

For me, since I don't use a mega-framework, I'd choose something light-weight, easy to pick up and configure, and something that doesn't get in the way of the normal usage of HTML/JS/CSS.

END Disclaimer

I've tried ToscaWidgets, ToscaWidgets 2, Formish, Deform, WTForms and FormEncode. I have to say none of them is anywhere near perfect. Here's my experience with them:

• ToscaWidgets, ToscaWidgets 2 - Extremely powerful, but also extremely complicated. ToscaWidgets 2 is much better but it's still quite alpha ATM. It takes quite a bit of ninja skills to setup and your code tend to bloat up fairly quickly whenever you need to customize the default templates.
• Formish/Deform - Almost as powerful as TW but Formish is dormant now. It's also quite tightly bound to Mako so if you don't use Mako, it's probably not for you. Deform is a rewrite of Formish but it brings in tons of Zope dependencies. Chameleon is also not quite there yet in terms of supporting other templating languages other then ZPT. These 2 libraries are also not particularly easy to setup.
• WTForm - Very simple, doesn't get in your way and it's very active in terms of development. It's nowhere near as powerful as the above libraries but it generally takes care of the 80% use cases you might encounter so it's good enough.
• FormEncode - Tried-and-true since 2005. Its well-tested, comes with the largest number of prebuilt validators, supports conditional validation, and useful error messages in dozens of languages. It also has a very simple but focused ability to generate form code in HTML prefilled with values and error messages. Its disadvantages includes a occasionally non-intuitive API and its absolutely spagetti-like internal code. However this library is quite dependable and fits very well in all the data validation use cases and it's the one I always come back to.

As of the end of 2012, a quick Google and PyPI search for a Python validation library comes back with hundreds of packages. There are a little more than a dozen notable ones, discounting those Django extensions, that are under active development. There seems to be a trend towards defining a schema using JSON-Schema and being able to generically validate Python data structures. This is likely a reflection of the server application developers' moving accepting user data from multiple channels (RESTful APIs and HTML forms), but remain wanting to use only one validation library.

Given the release of Python 3.3 will likely spark a massive movement towards porting existing libraries over to support Python 3.x (the flip side of that is seeing old libraries stagnant and remain compatible only with Python 2.x), it may be wise to choose one that already supports or is working actively to support Python 3.x.

Lastly, another great area of concern when choosing a form validation library is the ability to report useful error messages, which invariably includes the need for the localization of error messages in the long run. The ease of supplying your own error messages will quickly determine the complexity of integrating the library with the rest of your Web application architecture.

Promising up-and-comers:

• Voluptuous (Very popular, very simple API)
• Kanone (Inspired by FormEncode)
• Schema (Same author of docopt, very simple API)

Answer 2

I'd probably pick WTForms.