[GREP][#XE5] - Lot's of cheats on the code examples tab

[eaverdeja]

While checking out the code examples on XE5, I noticed there are a lot of examples using re and hardcoding the patterns the tester will use

Some examples even appear to be legit, with actual logic, but then they just degrade into hardcoding the patterns and leveraging re.match.

Is that something you guys could clean up? It’s a bit frustrating to try and compare my solution to others and find out that there were a bunch of cheats.

This probably happens in earlier stages, but I didn’t check.

Thank you!

[andy1li]

Hey @eaverdeja, thanks for highlighting the issue!

We’ve also noticed this and have implemented an anti-cheat mechanism to detect solutions that probably rely on built-in regex features:

internal/anti_cheat_quantifiers.go

That said, we haven’t yet cleaned up older submissions that slipped through. We’ll likely address this when trying to remove submissions that no longer pass the latest tests.

[eaverdeja]

Thanks for the quick reply Andy! Good to know this is already on your radar.

We’ll likely address this when trying to remove submissions that no longer pass the latest tests.

Thank you, that would be great! I’d love to study against the code examples, but right now it’s kinda of a mess for grep.

[eaverdeja]

For context:

I’d like to see other legit code examples because I noticed my code got quite messy as the test cases started combining things like quantifiers, character classes, alternation, backreferences etc.

I was curious as to how others tackled this complexity, that’s why I’m coming here with this clean up ask

[adecora]

@eaverdeja

While checking out the code examples on XE5, I noticed there are a lot of examples using re and hardcoding the patterns the tester will use

Hi, I’m using lark to parse the regexp pattern because is one of the libraries you provide and I’m forcing myself to use as I never use it before.

grammar = r"""
    parser: (negative_group | positive_group | alpha | digits | single_char | spaces)+

    negative_group: "[^" NEGATIVE "]"
    positive_group: "[" POSITIVE "]"
    alpha: "\\w"
    digits: "\\d"
    single_char: /[^\s]/
    spaces: WS

    NEGATIVE: /[^\]]+/
    POSITIVE: /[^^][^\]]+/

    %import common.WS
"""

But I also implement the same logic with re implementing a scanner to parse the regexp.

NEGATIVE = r"\[\^(?P<negative_group>[^\]]+)\]"
POSITIVE = r"\[(?P<positive_group>[^^][^\]]+)\]"
ALPHA = r"(?P<alpha>\\w)"
DIGITS = r"(?P<digits>\\d)"
SINGLE_CHAR = r"(?P<single_char>[^\s])"
SPACES = r"(?P<spaces>[\s])"

master_pat = re.compile(
    "|".join([NEGATIVE, POSITIVE, ALPHA, DIGITS, SINGLE_CHAR, SPACES])
)

Is this suppose to be illegal, as solution?

[eaverdeja]

I’m not sure why you have two competing implementations? But I wouldn’t consider that cheating - you are processing the pattern into something more manageable so your program can handle it.

What I mean by cheats are solutions that hardcode the input text and pattern the tester sends, just to pass the tests. There are quite a lot of these on code examples for later stages (talking about python specifically).

[rohitpaulk]

Quick update here - we took a closer look at this, and these aren’t cases that would trigger anti-cheat. Anti-cheat invokes patterns that users are unlikely to have handled (quantifiers are what we use I think), and checks if the answers are correct. Since these solutions are hardcoding patterns, the anti-cheat case doesn’t trigger – it still fails on “unknown” patterns.

We already have a mechanism to filter these kind of solutions out when displaying “Concise code examples” (more on that here: "Concise" code examples) – it looks like this wasn’t properly configured for the 3 stages in backreferences. We’re fixing this! For xe5 & Python specifically, this should already be fixed. The concise examples at the top should now not be the kind that use re.

We’ll backpropagate this to other stages shortly!

[eaverdeja]

Nice!!! Thanks so much for the quick follow up.

[adecora]

Ah, okay, I didn’t see any hardcoded solution. Honestly, there’s no reason to implement two solutions. In fact, I implemented them as two independent modules. I started using the standard library, but since CodeCrafters included lark and pyparsing, I tried replicating the same thing to see if it offered any advantage and thinking that maybe more people would use it s to compare my code.