Fix an incorrect usage of strip which caused bad formats to be read

[akariv]

No description provided.

[zhenyab]

@akariv could you please explain the use case?

[coveralls]

Coverage remained the same at 92.863% when pulling 3a0a490 on akariv:fix/bad-stripping into bfce923 on frictionlessdata:master.

[akariv]

This is a simple bug:

a.strip("fmt:") removes all instances of 'f','m','t,':'from the beginning and the end of the string.

e.g. 'fmt:%y-%m' will be converted to '%y-%' which is not what you'd want here (notice the ending m was removed)

[roll]

@akariv
Thanks! Will you bump version (0.6.5) in PR for quick release (as you did before)?

[vitorbaptista]

@akariv Interesting catch. Changing strip('fmt:') to lstrip('fmt:') seems to solve it as well, while keeping the code a bit more explicit than [4:].

Edit: Nevermind, lstrip('fmt:') is also not what it looks like. For example, 'fmt:format'.lstrip('fmt:') would return 'ormat', which isn't what we want.

[akariv]

@vitorbaptista not necessarily as fmt:my-format will still be decoded incorrectly (and result in y-format).
@roll done

[coveralls]

Coverage remained the same at 92.863% when pulling 4cb3112 on akariv:fix/bad-stripping into bfce923 on frictionlessdata:master.

[roll]

@akariv
I suppose here we also need fix fmt: instead of fmt - to avoid things like fmtX%y-%m

[akariv]

True. Fixed.

[coveralls]

Coverage remained the same at 92.863% when pulling 4cb3112 on akariv:fix/bad-stripping into bfce923 on frictionlessdata:master.

[coveralls]

Coverage remained the same at 92.863% when pulling c3020e4 on akariv:fix/bad-stripping into bfce923 on frictionlessdata:master.

[pwalsh]

more to the point, we need to remove fmt: from the spec: frictionlessdata/specs#260

[roll]

@pwalsh
I know but we're waiting spec for now to make changes here right?

[roll]

@akariv
released as 0.6.5 - https://pypi.python.org/pypi/jsontableschema