Fix for bug #40 for Password type (only)

[dbrumley]

Fix makes representation consistent with constructor call by printing
length as the expected max_length parameter. Note this helps downstream
alembic migrations work properly too.

[kvesteri]

Thanks for the PR. Before merging this needs unit test(s).

[frol]

This doesn't work for me when I use SQLite as a backend as it somehow uses sa.NUMERIC(precision=128), and I still receive a bloated autogenerated migration:

    op.alter_column('user', 'password',
               existing_type=sa.NUMERIC(precision=128),
               type_=sqlalchemy_utils.types.password.PasswordType(max_length=128),
               existing_nullable=False)

[dbrumley]

What doesn't work? The patch? I didn't put a unit test, so there was never a PR that incorporated the patch.

[frol]

I applied the patch locally, and it didn't help me.

[frol]

Oh, yeah, this patch at least helps to produce a correct type_ value using max_length= argument instead of the autogenerated length=, but Alembic's autogeneration still detects a change where it shouldn't:

Detected type change from NUMERIC(precision=128) to PasswordType(max_length=128) on 'user.password'

[dbrumley]

ah, that i did not look into.

[frol]

It seems that I wrongly assumed that #106 refers to that SQLAlchemy-Utils fields are getting into every new Alembic migration, at least that is what I experience using SQLite for prototyping. It turned out that the only raised concern was that incorrect length= argument passed instead of max_length=. I am sorry for hijacking your PR. While it addresses one problem, it doesn't (and, probably, shouldn't) address the SQLite-specific one, so I dug into this issue myself and as a result, I think the bug is in SQLAlchemy, so I reported it there: https://groups.google.com/forum/#!topic/sqlalchemy/GpkSJ0XUgwo

P.S. @dbrumley Why does your commit point to the issue #40? I think, it should point to #106.

[kurtmckee]

It appears that this PR is not going to get updated or merged. I recommend closing.