Add support for negative values

[Skuldur]

Added support for negative values in IntegerConverter and FloatConverter

• Added unit tests for the negative values

If this method is not preferred, lets discuss the best way to add signed values.

Closes #729

[Skuldur]

There seems to be a problem with the Python 3.6 run of the CI, that check has been failing for all pull requests in the past month. Which is why the checks fail.

[ThiefMaster]

This is a breaking change as applications may not expect negative values there right now; you could either add a new converter or an argument (like it's done for the AnyConverter).

Also, general tip: Having issue numbers at the beginning of a commit message is more noise than useful (especially when not prefixed with # so they aren't linked on github).
Better to use a concise first commit message line and then a closes #729 somewhere in a later line of the commit message

[Skuldur]

I've changed the name, thanks for the tip.

In my opinion this is not a breaking change but rather a bug fix (or might be both). Int implies that the input should allow any integer, the fact that it hasn't until now should be considered a bug as it is not expected behaviour for an integer parser.

However, I realise that a lot of people might be using the fact it doesn't allow negative numbers to skip writing their own error handling for invalid values (in the case of paging) so I will make two new converters SignedIntegerConverter and SignedFloatConverter as that will probably cause the least amount of tension.

Do you prefer the new types to be called 'sint' and 'sfloat' or 'signed_int' and 'signed_float'? :)

[ThiefMaster]

Bugfixes can be breaking changes as well if the bug existed for a long time and people likely relied on them. For example, the most common use case for int URL segments are probably database IDs. Usually those start with 1 (or 0), but aren't negative. Common usecase for negative IDs is to indicate special object types (e.g. a system user in case of a user id) - but if these can suddenly be specified in a URL this could be bad.

If backwards compatibility was not thing I'd change int and add uint for positive integers. sint came to my mind but the name sounds pretty awful. Since most likely the common case is unsigned ints, What about making it an argument?

• /foo/<int(signed):some_id>/
• /foo/<int(-):some_id>/
• /foo/<sint:some_id>/
• /foo/<signed-int:some_id>/

If we go for sint, I'd also add uint as an alias for the old int so one can be explicit in his own code.

[Skuldur]

Adding an uint alias shouldn't be too hard. But sint might confuse people since it is commonly used for short integer. So I think we should not use sint for signed integer.

I think either
/foo/<int(signed):some_id>/
or
/foo/<signed-int:some_id>/

Should be the method we use. I have no strong preference for either one, but signed-int might be easier to add.

EDIT: Werkzeug does not allow - in their url rules so we can rule out signed-int so we're down to signed_int or adding (signed) as an argument.

[Skuldur]

I've updated the method of support to

/foo/<int(signed=True):some_id>/

[Skuldur]

Any other comments?

[davidism]

Rebased, added changelog, and refactored. signed is now a parameter of NumberConverter, and allows overriding the signed_regex attribute.