This problem statement is not great.

The table and column names should be clear and consistently formatted.

Table name: people
Column names:
id (PK int),
age (int),
otherdata (datatype),
...

Formatting is not very thorough in these problems.

The most offensive line is "Count the number of digits d used in the writing of all the k**2"

Very unclear.

It should be written as "Count the number of occurrences of digit d in all squared values between 0 and n inclusive"

Also, the phrase "Note that 121 has twice the digit 1"

Is a little off, and should be written "Note that 1 appears twice in 121"

Is it necessary to write "Square all numbers k (0 <= k <= n) between 0 and n"

when "Square all numbers between 0 and n inclusive" would suffice?

Specifying that digits fall between the range of 0 and 9 inclusive is redundant; using a base 10 digit system is implied.

Revised Problem Description:

Return the number of occurrences of digit 'd' in the set of squared numbers between 0 and n inclusive

Constraints:
(0 <= n <= 1_000_000)
# NOTE: The problem theoretically includes infinitely large numbers. There should be a constraint for n other than n >= 0. Also, neither k nor d need to be specified as a range.

Revised Examples:

Example 1:
n = 10

d = 1

The squared numbers between 0 and n inclusive are 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, and 100

We are counting the number of occurrences of the digit 'd' in the squared numbers.

There are 4 instances of '1' in the squared numbers, so the answer is 4.


Example 2:
n = 25

d = 7

The numbers between 0 and 25 squared are: (list all the numbers between 0 and 25 squared)

There are {number of occurrences} of the digit 7 in the list of squared numbers, so the answer is {number of occurrences}

Understood.

Seconding what everyone else said, this description is confusing and unhelpful, especially for a 7-kyu problem. Provide more examples and make it more clear, please.

Variable names evoke sadness

Clever, but not efficient. Nit: should space around operators by default to improve readability.

Not even a flex since returning 0 is an incorrect response if a string '3' were supplied. The robustness of this code is an illusion.

Probably best not to assign i to int(s). It's more concise just to write return int(s)