Removing Python since C# is complete and I need time to make it use a bytes approach

Appreciate you! I'll get on that when I come back to the Python edits!

Corrected.

Makes sense. Went and reduced the 'super large' tests and reduced the overall number of tests period, since FNV1 is fairly simple to implement.

The reason strings are used is because the usecase for FVN I found was for implementing a Blackboard pattern, where FVN is the hashing method used for <string, value> pairs. Plain strings are more commonly used in programming in general anyway, so the function assumes that and the onus is on the writer to manage the strings-to-bytes conversion themselves.

Additionally, in most languages, since reading in bytes from a string is trivial to execute and lookup, I believe leaving it in as an exercise for the writer is fine.

Open question to folks, given that Python (and other int unbounded) languages don't deal with int <-> uint like others, but result in the same Hex values, do you think I should validate the hex output of the functions?

I could force the strictly-typed and bounded behaviors of C-like code languages, but I wonder if that'd put too much undue extra work for those freer languages.

I don't like the fact that I have two different hardcoded validation values for Python and C#...

And the people have spoken! I'll take out the starter code and we'll see what people come up with!

Addressed! Got em fixed up in both C# and Python. Hopefully that prevents the issue going forward.

Oof, thanks for the heads up! I'll do that ASAP.

Thanks for the feedback! Glad someone likes it already :)

As for the boilerplate, Id be fine with either, but I think having some standard structure doesnt hurt, since I dont think as written it gives anything away. (Makes reading solutions easier too IMO)

Since the main burden of the kata was figuring out how to manipulate the language operators and the casting properly, I'd go further and say I wouldn't have minded leaving the required hash parameters present.

The external research required (if any) is just an added task for the reader to provide some realism to a minor research focused problem.

A little rough to say I "ruined" it with performance, don't ya think?

That said, I see including a large data parsing requirement as similar to the difference between someone solving a software problem for a small local business versus a Fortune 500 company. Being able to code solutions for data at scale can make a huge difference in someones paygrade.

As Chrono said, theres just a slight syntactical difference (parentheses "()" vs brackets "[]") that Python treats very differently as two different types of data structures: lists and tuples.

The most basic difference is that lists are mutable (you can rearrange the order of things inside them) and tuples are not.

That said, there are other differences that are important when deciding which to use. Here's docs with more information: https://www.geeksforgeeks.org/python-difference-between-list-and-tuple/

Was able to copy-paste your done into Ideone and get it working after removing the JQuery-style "${}" elements and it returned [1, 7] as expected.

I'd say double-check the output with print statements just in case.