description: don't mention null. strings are not null. null is when you DON'T have a string. which we do. that's already specified.

it has not been removed

Traceback (most recent call last):
  File "/workspace/default/.venv/lib/python3.11/site-packages/codewars_test/test_framework.py", line 112, in wrapper
    func()
  File "/workspace/default/tests.py", line 28, in test_basic
    test.assert_equals(octopus(None), "")
                       ^^^^^^^^^^^^^

and I have zero intuition telling me that spaces only are special in any way, that's a special case slapped on there and if you look at solutions, all it leads to is everyone writing the same code for it as a special case at the top of the function. it's functionally the same as a null check.

additionally the non-digit, non-space, non-alpha characters are unspecified and most of them are only tested in a single large test which is not all that fun to sift through, and the selection tested for seems arbitrary and incomplete.

epsilon of 1e-15 is used but is too small because that would be +-1 21st digit where a double only offers 15 or so

love seeing ai word salad in the comments

Other people don't know what "wrong" means. That word is relative to your expectations and observations, and you're not sharing those.

It checks equality, not integrity, whatever that is. And for primitives they do the same thing. And if it was wrong, then it wouldn't pass tests unless tests only tried even numbers ..

@Carl98K 0 and +0 evaluate to the same thing, you wouldn't be able to detect a difference as no difference exists between two of the same value. The problem is that your algorithm is flawed - you are reading from and writing to the same object without taking care to ensure that the writes don't affect the reads. Like peeing upstream and then getting it in your drinking water.

-0 would be another matter. that is a distinct value. but I don't think those are included.

no no no, not you. the test framework.

the Fork link is near the top left right corner of this page

what about line breaking the failure message so it's one over the other?

expected: 'r q n k b b r n\np p p p p p p p\n. . . . . . . .\n. . . . . . . .\n. . . . . . . .\n. . . . . . . .\nP P P P P P P P\nR Q N K B B R N\n'
but got:  'R Q N K B B R N\np p p p p p p p\n. . . . . . . .\n. . . . . . . .\n. . . . . . . .\n. . . . . . . .\nP P P P P P P P\nR Q N K B B R N\n'

as the test framework should already be doing by default. why exactly have we still not had that changed?

that's not accurate. you're forking old code instead of the current code.
I guess you figured it out

If you don't describe what the problem is so that others can see it, then you have not reported a problem. This is an invalid issue.

I understand, I forked it and tried to fix most of the problems without modifying the original too much, I think in the end it didn't work out very well

Fewer, but also all*, and deterministically so. (*though at most three different digits). They could be picked out and be randomly renamed again I suppose, if it's at risk of passing by fluke.

def replicate_tricky(xs):
    for x in xs:
        if is_tricky(x):
            for _ in range(3):
                yield int(rename(str(x), randomnames()))
        yield x

testcases = shuffled(take(500, replicate_tricky(testgen())))

You've still got assertions outside it. The cw test framework really ought to error out on that, but it's made out of chewing gum. Assertions are only allowed in it, describe is optionally used to group it's, similar to curly braces in C grouping statements.

@test.it("")
def _():
    # assertions allowed here
    ...

@test.describe("")
def _():
    @test.it("")
    def _():
        # assertions allowed here
        ...

@test.describe("")
def _():
    # assertions NOT allowed here
    ...

Additionally, describe may be nested, but it may not.

The "Tricky Doubled!" is .. still looking strange to me, because it'll produce:

Tricky Doubled!: 1 should equal 444444

Which.. I don't know how to read that. It would also be nice if it stated what the input was, because printing it out is busy-work and sometimes confusing. Ideally I would have it read similar to:

tricky_doubles(222222): expected 444444 but got 1

or I suppose

tricky_doubles(222222): 1 should be 444444

which may be more convenient I just happen to disagree with that wording

I implemented your test cases, it seems reasonable, but it is generating a much larger amount of numbers that should be doubled, than tricky doubles, anyway