Ban "regexp" package and external libraries

Thoughts on banning “regexp” package or any other external dependencies for the grep challenge? (Go language)

I’m looking at solutions and see people passing stages using built-in regexp packages, defeats the point of this challenge…

Nice catch. I think we’re missing an anti-cheat stage for this challenge, that should cover this.

@sarp do you happen to recall whether you were seeing this in a “Concise” code example (the ones highlighted at the top)? We do have a system that’s supposed to filter out these cases for Concise code examples, so it’s definitely not expected there. The other examples are just sorted chronologically so it’s possible that you’d see such usages there (will get filtered out once we add in anti-cheat).

No, they weren’t marked as “Concise”
I saw a few looking at “Single Backreference” extension solutions

1 Like

Cool! Will keep this open until we add an anti-cheat stage

Does it matter if people “cheat”? If you choose to use an external module that does the challenge for you, why should others care? By the same token, one might search for git repos of others who did the codecrafters challenge, and pass all of the stages at once.

From my perspective, implementing “anti-cheat” is a waste of time. You might want to filter e.g. the regexp package so that it doesn’t show in the code examples, but otherwise, my 2c is that it’s not hurting anybody (except for the person who wrote the code :slight_smile: )

It’s resulting in low quality solutions that don’t help others, especially when you’re browsing other people’s solutions. I’d rather not have those waste my time when browsing Code Examples.

2 Likes

Yep, agreed, codecrafters could either:

  • Filter those from showing up in the code samples, or
  • Enable users to hide the submissions manually :slight_smile: When enough people hid them (e.g. 10+), codecrafters just skips showing them for everyone.

The problem is then not with “cheating”, but with the submissions not helping others.

But returning to the original post, I would advise against implementing anything that prevents users in passing the test, e.g. what if user defines their own “regexp” package and then experiences problem with submission because of a false positive on the anticheat side.

Another thing to consider, which I thought would not be allowed already even, is just using the grep util from the language’s OS package/library.

I was frustrated with my own failure to pass the final stage of the challenge and just for the joke thought to use Rust’s OS library to just spawn a grep process and pass the regex and input string to it, thinking I would get banned or failed or whatever.

It just passed all of the testcases. While I may have benefited from it(questionable), I don’t think this something you should leave in or allow.

As of writing, the two pieces of sample code available to me on Grep #XE5 (Nested Backreferences) are a) both marked as “concise”, b) both use the Python regular expression library, and c) often pattern match directly to the test cases, eg " if pattern == “\d\d\d apples”
". I guess this is added incentive to pay for a subscription!

Closing this thread due to inactivity. If you still need assistance, feel free to reopen or start a new discussion!

Just adding context here - we’ve added extra checks to prevent using regexp libraries! We haven’t removed the old code examples yet, but we have a feature in the works to re-run tests on older code examples and highlight ones that no longer pass tests.

1 Like