-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
['1.100', '1.10', '1.1', '1.54'] etc do not sort properly... #13
Comments
Elements like |
Hey @overset, did you ever come up with a solution for this? I also have same problem where for example |
+ added better unicode locale support fixing #9 + added regex lookahead for better chunking with mixed number/strings + fix for #13 (comment)
@harisb - I posted a fix for your example in v0.8.1 >>> ['2.2 sec','1.9 sec','1.53 sec'].sort(naturalSort)
["1.53 sec", "1.9 sec", "2.2 sec"] I kept the float inference for strings that resemble numbers, e.g. >>> ['1.100','1.1','1.10'].sort(naturalSort)
["1.1", "1.10", "1.100"] >>> [1.100, 1.1, 1.10].sort(naturalSort)
[1.1, 1.1, 1.1] An original design feature was to coerce as many string values into their native data type as possible but this could be simplified and made more consistent. |
Awesome, that works! Thank you! |
Should this issue be closed? |
The fix for '2.2sec' breaks version numbers like '1.1a'. Compare:
The problem is determining the difference between a floating point number and a two-level version number. I think making floats be a 'word' on their own may work more intuitively. That way, '2.2 sec' would sort as expected, but things like '2.2sec' and '1.1a' would still sort as version numbers (even though to a human, the former is obviously not). My two cents. |
3eabc73 breaks the unit test. |
No description provided.
The text was updated successfully, but these errors were encountered: