Add GenderType

[singingwolfboy]

This is meant to integrate with kvesteri/wtforms-components#41

[kvesteri]

Hi, thanks for the PR. I think it would make more sense to store the genders using type CHAR(1). For more information see:

http://stackoverflow.com/questions/4175878/storing-sex-gender-in-database
http://ocelot.ca/blog/blog/2013/09/16/representing-sex-in-databases/

[singingwolfboy]

@kvesteri: the whole point of this pull request is to account for non-binary genders. See nonbinary.org for more information.

To clarify, there is a difference between "sex" and "gender". "Sex" is a biological term, and it refers to what you have between your legs. "Gender" is a social term, and it refers to what you have between your ears (your brain). This pull request adds a GenderType, which can account for the wide variety of genders that people can express, including transgender, genderfluid, non-gendered, and so on. Because of this wide variety of genders, this GenderType stores data as a lowercase string.

Non-binary people are effectively invisible in modern society, but that is beginning to change. Adding this data type and form field will make it easier for developers to build web applications that can support non-binary people, if they so choose. If developers choose to not use this GenderType in their database models, and instead continue to represent gender using 1 bit of data, there's nothing stopping them from doing so. I simply want to make it easier for developers to support non-binary people.

[singingwolfboy]

Test failures in Travis appear completely unrelated to the contents of this pull request. @kvesteri, can you take a look?

[singingwolfboy]

Hey @kvesteri, any updates on this pull request? Still looking for some help with the tests -- or if you've fixed them in a separate pull request, let me know and I can rebase my work.

[kvesteri]

Thanks for clarifying the issue. I fixed the tests.

I'm not sure I want to add this as a data type on this package though. Each data type should have a good purpose in terms of solving some actual developer problem on ORM level. I'm not too fond of adding support for certain data type just for the sake of other form libraries.

One could argue this data type would be pretty similar to EmailType. Even though RFC 2821 states emails are case sensitive the de-facto standard is they are case insensitive and adding this data type solves an actual problem of comparing the emails and adding them as lowercased strings in database. So EmailType solves to problem of developers adhering to this de-facto standard.

Also I've been planning to make the EmailType return an Email object which would provide similar helpers as URLType.