Note: do not print to the system stdout, only python stdout.

I am a total Python noob, what is python stdout, but not system stdout?

Unpublished due to the violation of the Codeforces license:

"It is forbidden to publish Codeforces problems in open sources supporting
automatic testing (such as online judges or similar resources)."

I think this is a very good kata that needs some additional work. For instance there's both "open" and "closed" hashes... so:

• If the tests are going to require a specific implementation (let's say an open hash), then I think it should be mentioned that it's expected to have it implemented as such,
• then it could be a good idea to state specifically that it's required a certain key of a certain type, let's say _entries to be in the object, and then validate that, instead of validating that there's only a single list attribute.
• Tests should then validate that this _entries: list[LinkedList] is actually being correctly populated (and so it should me mentioned in the description).
• Please add typing annotations!
• I think that if this _entries key is required and validated, then there's no need for anti-cheating.
• Moreover, some tests could even overwrite _entries and expect the reading methods to work, that way cheating would make no sense at all.

What does everyone else think?

A hash map is unordered by definition, which means it doesn't have key/value order, so asking .keys/.values/.items to return a tuple, a frozen list, is inappropriate. It should be at least a frozenset, or to be precise, a view-like object.

(Python didn't mandate insertion-order preservation before 3.7, so this property in view-like objects should be seen as a bonus, not a norm.)

The anti-cheat tests are pathetically weak.

I do not believe the current design of the kata would work at all, because it's trying to enforce an implementation while the tests are probing the behaviours instead. Hashmap = {} would satisfy all the behaviours, the kata just didn't like it ;-). To enforce a partciular implmentation you'd at least need to do these things instead:

• Put LinkedList in Preloaded, and enforce user code to use it
• Have the test code decide what hash function to use, so you have full control over how the hashing is done
• Actually test the internal structure to be exactly equal to an expected one

Otherwise you cannot make any claims that you actually know what the internal components of an unknown Hashmap is implemented.

The description does a very poor job describing what size is. Is it the bucket size or the capacity (number of values it can store)?

Moreover, size isn't directly tested at all: the tests at best do it in a very roundabout way.

There are still test.expect assertions in the tests that do not have a message supplied, which are just displayed as an unhelpful value is not what was expected

How many decimal has 4.12300000000000022026824808563105762?

And 4.123?

P.S.

In [1343]: 4.123 == 4.12300000000000022026824808563105762
Out[1343]: True

Test framework and solution should be imported explicitly.

The describe/it blocks' structure in the tests is wrong.

The reference solution is wrong:

input | reference
------+----------
0.015 | 0.01
0.045 | 0.04
0.075 | 0.07
0.105 | 0.1
0.125 | 0.12
0.145 | 0.14
0.155 | 0.15
0.175 | 0.17
0.185 | 0.18
0.205 | 0.2
0.215 | 0.21
0.235 | 0.23
0.245 | 0.24
0.285 | 0.28
0.295 | 0.29
0.305 | 0.3
0.345 | 0.34
0.355 | 0.35
0.365 | 0.36
0.415 | 0.41
0.425 | 0.42
0.435 | 0.43
0.475 | 0.47
0.485 | 0.48
0.495 | 0.49
0.565 | 0.56
0.575 | 0.57
0.585 | 0.58
0.595 | 0.59
0.605 | 0.6
0.615 | 0.61
0.625 | 0.62
0.695 | 0.69
0.705 | 0.7
0.715 | 0.71
0.725 | 0.72
0.735 | 0.73
0.745 | 0.74
0.815 | 0.81
0.825 | 0.82
0.835 | 0.83
0.845 | 0.84
0.855 | 0.85
0.865 | 0.86
0.945 | 0.94
0.955 | 0.95
0.965 | 0.96
0.975 | 0.97
0.985 | 0.98
0.995 | 0.99