Retired

Those élégantes unïcôdes, hiding in code wars... (retired)

Description
Loading description...
Unicode
Fundamentals
  • Please sign in or sign up to leave a comment.
  • anter69 Avatar

    Should mention in the description that some characters translate to multiple characters, and what exactly:

    • Æ --> Ae
    • æ --> ae
    • Þ --> Th
    • þ --> th (this is a guess, haven't seen it in the tests)

    Also: ß --> B? Phonetically it's ss; but if you're translating the letters visually, then Þ should translate to b or p, not Th...

  • tachyonlabs Avatar

    In addition to the "string_types" error below, when I have my solution also print my results in addition to returning them, I'm seeing this with Python 2:

    Random test cases with unicodes
    Log
    IiEdc  lu  tOO AnfsrHcAcUfacAEO tU etoeACh AIaseeItlAPOeEUreOAarlDh:iEsNIYU
    Expecting 'IiEdc  lu  tOO AnfsrHcAcUfacAEO tU etoeACh AIaseeItlAPOeEUreOAarlDh:iEsNIYU'
    

    Maybe I'm missing a big duh here, but those seem to be exactly the same.

    Though as there are still (at least :-)) a couple things I need to clean up in my code, I think that maybe your tests have the expected vs actual backwards, so that the reason my output and the expected seem identical are because the error is also showing my output instead of the actual expected.

  • zebulan Avatar

    @ebreton,

    I'm trying to submit a solution but I keep getting this error: NameError: name 'string_types' is not defined. It comes up when I click Run Suite and the first random tests start. Is that a variable you defined? (I haven't checked the Test Cases code because I haven't been able to submit a solution successfully yet)


    I am not a fan of using a for loop in the Example Test Cases. I think it goes against the Codewars Python Test docs and over-complicates the Example Test Cases. The only reason I can really see it being used for is if you were going to use the input variables for something other than the test.assert_equals.

    In this case, you are using the out variable for a test.it message but I would argue that it is unnecessary. If the test.assert_equals returns False, there is automatically a message of the format "{actual} should equal {expected}". In my opinion, that makes your test.it message a duplicate of the default message but with half as much information (since the "actual" value is missing from your test.it).

    # keep it simple!
    test.assert_equals(asciify(u'\xe9t\xe9'), u"ete")
    test.assert_equals(asciify(u"ete"), u"ete")
    

    Thanks again for writing these katas!

    • tachyonlabs Avatar

      I'm getting the same error with the full test (though my solution runs fine with the example tests).

    • zebulan Avatar

      @tachyonlabs,

      Ok, good to know it wasn't just me! I actually played around and made my own string_types = (str,) and then the error was something like text_types so I made one of those too, no luck so far.

    • ebreton Avatar

      Right and right ^^

      I missed an import in my test cases. Not flagged out because it is in my solution and the two are joined when the kata is validated. -> should be corrected now :)

      I also modified the test samples. Thanks for the tip! makes sense

      Cheers to both of you :)

    • zebulan Avatar

      @ebreton,

      Ok, thanks for the fix! I'll try to solve it again in a little while.

      Suggestion marked resolved by zebulan 9 years ago