Please mention in the description that different providers can have the same name.

• description should be reworded, especially the part where each gift is raised to an exponent of two when calculating the score.
• input type should be different, maybe in the form of a dictionary
• fixed tests for handling ties

The description is not too clear; not sure what to suggest - perhaps use code blocks for the examples and follow through from input to output within the same code block?

The input parameters are crazy - the name being the last element of the list is just... wierd - guess it's too late to change that now, and it just adds to the challenge.

You need a test where a name is on the gift list (e.g. 'Kitty'?) such that counting that name as a gift from that name produces the wrong output.

Expected result for fixed test #2 doesn't seem to correspond to the description. Shouldn't the giver who gave the least desirable gift be listed first, and the giver of the most desirable gift be listed second?

The description is so unclear, I can't tell if the fixed tests' expected results are wrong or the description just needs to be improved.

Hi, there's some mixed-up text in the description. It's not a major problem, but it would be better to correct it for clarity.

("Plastic Car", "Orange Water Mellon", "John")
#John's gift. ("Cat Food", "Bob") #Bob's gift

And you might want to consider using Markdown, which is recommended in the codewars guideline

happy birthday!

the list of words contains duplicate values, which can mess up the first argument

suggestion part:

• the small random tests should come before the "not small random tests" (otherwise the user is still first facing a wall of text)
• you should generalize the two batches of random tests, using a function and passing what changes between the small/not small batches as parameters of that function
• leste = tuple(random.sample(words, random.randint(2, 6))) -> here, you could keep random.choices, because one person could offer the same gift several times
• lst, lst2, leste, s, o, ... => choose more carefully your variable names. Moreover-and-above-all, don't ever name a variable with something that evokes something else than the actual type of the value. Typically, lst and alike are for lists, not tuples.
  • lst -> desired_gifts
  • lst2 -> offered_gifts
  • leste -> rnd_gifts
  • ii -> _ (because it's an unused variable)

(I didn't take a look at the description yet)

Issue part:

The number of offered gifts (ie. the number of tuples given as arguments) must also be random. To accomodate this with the function calls, just replace func(lst, lst2[0], lst2[1], lst2[2], lst2[3], lst2[4], lst2[5], lst2[6], lst2[7], lst2[8], lst2[9]) with func(lst, *lst2) (but with proper variable names... ;) )

Hi again,

Moving the technical parts to another issue:

• not engouh fixed tests
• needs a a batch of small random tests, to ease debugging (=> using small tuples, and small number of gifts)
• the gifts (first tuple) can contain the same gift several times => this doesn't make sense (ie. don't use choice, but sample)

Cheers

Hi,

Well... The description makes no sense. Moreover, the initial solution is incomplete (see point 4).

• inputs section: the arguments name should be given alongside the tuple
• ...and n gifts (Also tuples) => the structure of the gifts isn't explained. Which is really a problem when their lengths start to vary
• how the order should be determined when one person offers several gift?
• I guess you expect the user to use varargs as function arguments. In that case, the description is misleading: he gives you a tuple of things he would like to get (Sorted from the least wanted to the most wanted.) and n gifts (Also tuples) -> this is contextual and the user shouldn't have to guess that this is actually implying that the function will be called with n+1 arguments. The first is just storytelling and implies actually nothing about what the arguments of the function are. So the description must clarify this.
• powers of 2 are suddenly popping everywhere in the description without a single explanation about their role => must be clarified.
• Value of John's gift is 0, and Value of Bob's gift is 2. => Why? sum? min? what if John second gift is also CatFood? => must be sepcified

What the description should do:

1. describe the context/story/goal
2. give the specifics:

• inputs / how they are structured
• how they are used
• how they are compared
• describe the output

what the description is currently doing and shouldn't be doing:

• mix story and specs
• drop information without explaning the context (powers)
• hide specs behind assumptions/back story
• use cryptic notations without explanation. Out of context, lego brick - 1 (2**0) could be read as "minus 1", which doesn't make sense. Just spell it out: The value of "Lego Bricks" is 1, because 2**0=1

side note: if you keep blocking reviewers, you'll just lose the authoring privilege. This is your only warning.

Cheers

Hy mate, first of all, happy birthday!!!

I had a great time solving this kata; I loved the thematic and examples. I always appreciate when a creator includes a little story at the beginning.

I just had a little problem I'd like to address. I'm not a moderator, so take my advice with a grain of salt.

Issue

If given repeated gifts in the gifts he would like to get, what should be done? For example:

Given: ("Lego Bricks", "Cat Food", "Cat Food")

Should "Cat Food" be worth 2 or 4?

Suggestion

If this is a mistake and the given list is supposed to be unique, you could try using the choices function from the random module; it will pick k elements without repetition from the given Iterable.

Otherwise, please specify what should be done in case we receive repeated gifts in the first input.

Side Note

There are a few grammar mistakes in the Story section; I'm not one to judge, but there are people who aren't big fans of this.

As someone who has English as their second language, I often use QuillBot to verify my writing; maybe it could be helpful to you too.

Final

Don't let this discourage you from making other katas; I'm sure you'll improve your craft with sufficient practice. Also, don't take the mod's criticism too personally; they can be pretty harsh at times.

Hopefully I didn't sound condescending throughout this comment, and I apologize if I did. Anyways, best of luck, mate, and happy coding.

Also, sorry, mods, if I'm not supposed to do this.

Many issues with this Kata:

Description is vague and difficult to understand

Example:

Lego Bricks - 1 Cat Food - 2 Intercontinental Ballistic Missle - 4 A Single Piece Of Paper - 8 (The rest is 0)

It's entirely unclear how these "values of elements" are derived from the input tuple alone. One could extrapolate and guess that the values of each element should be determined as increasing powers of 2 based on the index within the input tuple, but it's not explicitly specified which is not acceptable.

Poor choice of data structures

Tuples are good for data where the number of elements are pre-determined and fixed. They are not for data where the number of elements are variable and cannot be pre-determined - use a list instead.

Broken tie-breaking logic in reference solution

Python's built-in sorting functions are stable by default so input order should already be preserved - see my solution below for an example.

On the other hand, the reference solution does not always preserve input order - it's difficult to present a concrete example given the way the inputs are structured for this Kata but it's possible to confirm this by printing a transformed view of the inputs and comparing the output of my solution from that of the reference solution.

Please refer to Creating your first Kata for guidelines on authoring a good Kata.