-
Notifications
You must be signed in to change notification settings - Fork 11
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
Soundex Appears Broken? #14
Comments
Hi, same for me on python 2.7, please see example below.
I had to put back previous version 1.1 :
|
As you can see, little changed with fuzzy.pyx from 1.1 to 1.2, and it changed slightly from 1.2 to 1.2.2. |
Hi, thank you very much for your answer. macOn mac as you mentionned (OSX Sierra 10.12.6) it's not OK either: it doesn't show any error but the return value appears to be wrong: with 1.2.2 We should have this instead: It may be noticeable that the function on newer versions returns unicode type rather than str as before. LinuxOn linux debian 8.2 jessie (with both versions 1.2 and 1.2.2), this may interest you : with 1.1 with 1.2.2 Also below: sorry for the repetitions but this may help if you look at the the third attempt: the return value remains wrong but it doens't throw any error!
>>> sdx('Test')
and so on... |
I tested the sample code from the documentation with versions 1.0, 1.1, 1.2, 1.2.1 and 1.2.2 on a GoogleCloud Ubuntu 16.04 instance:
Versions 1.0 and 1.1 produce the expected results 'F200'. Versions 1.2 onward produce empty strings. |
It seems to me that two weeks ago, version 1.2.2 used to work for us --- but then something changed and the results are wrong. Also, the results are sporadic --- we get different error messages in different runs of the program. For the time being, we go back to version 1.1 -- but it is not clear whether this solves the problem. I would think that a basic test for the Soundex function should not be marked as "expected to fail": If the test doesn't produce the correct answer, then there is some problem that needs to be corrected (and people should see that when they decide whether to use the package or not). |
Hi, I'm porting my project on python3 and it seems that the library doesn't work as it should with Soundex, as @metaperture reported earlier. Please see examples below:
The "test" string "fuzzy" does not give the expected result and a string containing accented character throws an exception. Thank-you in advance for your help. Regards, Philippe |
I've personally given up and used another implementation (https://pypi.org/project/soundex/) |
As I'm not the original author, I have little visibility to the project, so I can give little guidance to what this library should be doing, so it's nice to know of the Thinking about @pw717's comment above, it seems to me that on the mac, the behavior on 1.2 is more correct than that of 1.1, especially considering that the trailing zeros seem like padding, but also because the soundex lib doesn't render them either:
|
There are several issues at play here. Let's set aside for the moment the issue that non-ascii characters are not yet supported (as the encoding for strings is declared to be ascii). I'll file that as a separate issue for clarity. Excluding that issue, the tests pass on macOS. What we need is someone to spend some time to understand the Cython code and dig into the details on a system where the tests are failing and devise a fix. |
Soundex also has other bugs:
This is on Python 3.7.0 (macOS 10.14) with Fuzzy 1.2.2 |
I am getting weird errors. Sometimes, I am getting blank strings with return carriage. Sometimes, I am getting this error. Traceback (most recent call last): |
Using the test case, in python 3.5:
yields:
''
Occasionally instead of yielding an empty string, it yields a unicode error.
dmeta
andnysiis
are working fine in this install, so I don't believe it was an install error.The text was updated successfully, but these errors were encountered: