Documentation surrounding compare_type context param.

[peterschutt]

In more than one place (here, and here), the docs state that noticing changes in string length will not happen, even if compare_type=True.

In responding to a SO question, I tested (very rudimentary) on PG and MySQL and notice that it does pick up a change in string length on both of those once compare_type is set.

Would you welcome some clarification to the docs here, or is this a feature that you aren't ready to commit to perhaps? I'm happy to chip in with docs changes.

Thanks for all your hard work and the great tools:)

[zzzeek]

I was surprised to see there's a length check but apparnetly it's been there for many years so sure I can accept minor documentation edits to this effect.

[peterschutt]

Hi Mike,

Sorry it's taken me a little while to pick this up. Following on from above, I notice that both of those doc sections also mention that Precision is not compared:

...and does not detect changes in arguments such as lengths, precisions, or enumeration members.

however this func:

alembic/alembic/ddl/impl.py

Lines 434 to 439 in afefd1b

	def _numeric_compare(t1, t2):
	return (t1.precision is not None and t1.precision != t2.precision) or (
	t1.precision is not None
	and t1.scale is not None
	and t1.scale != t2.scale
	)

...seems to be checking precision of numeric types. Have I got that right? If so would you like me to revise that as part of this PR too?

It appears that of the "within type" arguments that are documented as not being checked, only the Enum warning still stands relevant.

[zzzeek]

Sure, you can document what is compared for now, this series of behaviors are also in flux as in #605 we might get more accurate comparison. but for now yes that's what we have, that stuff got added at some point without being updated in the documentation (as this whole area of functionality is in flux often) thanks!