Draft

Python One-Liner #1: Introduction

26user6270586
Description
Loading description...
View
AllIssues2QuestionsSuggestions1Show Resolved
  • Please sign in or sign up to leave a comment.
  • user6270586 Avatar

    Hmm, okay. I'm going to close the one-liner series for now. I first thought that we can just rely on one's honor to actually code in one-liner, but it seems not only to depress the challenging feeling, but also to make a bad example of Kata that would require similar tasks. There MUST be a part for verifying the answer, and it seems to be complicated enough as parsing the source is obviously needed to ensure the rules.

    Nonetheless, thanks for valuable feedbacks.

  • Caders Avatar

    You don't have to change anything? :(

  • PistachioCake Avatar

    How does this kata decide if the solution is a one-liner? Does (or can) the author dock honor from those that do not use one-liners?

  • adam-tokarski Avatar

    I was always wondering how do you make all your amazing one-liners. I'm glad you're going to teach us those technics!

    As for the possibility of verifying if solution is indeed one-liner, I think I see one solution, but all tested items should be functions only. I use it in my Kata (http://www.codewars.com/kata/my-very-own-pythons-split-function/python) for verifying if is used generator function (as is said in description).

    • user6270586 Avatar

      That's very nice way to enforce generator. I've actually failed to get through one-liner before seeing the test code. That disassembly approach was quite aggressive. I have no clue to apply similar approach to this Kata though. So far I had no luck on differentiating between regular codes and one-liner equivalents using dis.dis() or any other inspect functions.

  • zellerede Avatar

    It would be best to verify somehow that the solution indeed uses one line only. Unfortunately inspect.getsourcelines seems prohibitted.

    • user6270586 Avatar

      Yeah I tried that before, but I couldn't get it to access the source.

    • zellerede Avatar

      I think I found a cheating solution for that. Well, not too nice, but might work:

      • In the preloaded part, put CODE = '''
      • Then the (initial) solution must end with '''
      • Now, in the beginning of (custom) tests, call exec CODE
      • Finally the string CODE can be parsed to verify the onelines.
    • user6270586 Avatar

      Hmm. It might work well since we can do something like:

      #NOTE: DO NOT REMOVE THIS LINE WHEN YOU SUBMIT THE CODE! '''

      I'll definitely try it. Thanks.

      EDIT: Hmm.. It seems that it is not as simple as I thought. Additional restrictions will come up like:

      • Definitely, you cannot use blockquote inside the code.
      • Escaped string inside the code will make additional complexity. It is true even when using raw literals, i.e. CODE = r''', as it has different parsing rules. I'm not sure if it's free of any side-effects.
      • It is completely skippable by just coding outside the blockquote (i.e. after '''). Well it can be forced by using scope directive in exec, but it is trickier than I thought.
    • zellerede Avatar

      I don't exactly get your difficulties.

      • The idea of the last line comment ending with ''' is very nice.
      • I bet nobody would use ''' inside their code anyway, so maybe we don't even have to mention these restrictions in the description.
      • You can just issue plainly exec CODE in the beginning of the tests, and then nothing else needs to be modified. Why would anyone use escaped characters in the given exercises? Also, I guess, the most common ones, \n, \s will work anyway.
      • Additionally, issue test cases that parses regexps in the string CODE and checks that the solutions are indeed one line, e.g. search for a line containing r'a_simple_function\s*=\s*lambda'.
      • Maybe we can require in the description that after each oneliner solution, place an empty line that makes the indeed one line testcases much easier to implement.