Approved by someone

python new test framework is required. updated in this fork

Well, the kata "works" as it is, hence rather a suggestion.

I used option #1 in all my solutions, but as I said, it doesn't make a difference because it's not tested in any language.

shouldn't this be an issue, actually?

What did you use for the translation? way 2?

While translating the kata, the question that arose back when I first solved it reared its ugly head again:
The builder is entirely capable of calling a base coffee type twice in a single chain, and it is not specified what effect exactly this should have.
Accordingly, it is never tested for, though a correct solution should handle such a case, and I believe we should be promoting correctness wherever possible.

Imagine a case like Builder().cubano().with_milk(1.0).americano()
Note the trailing americano(), a new base type. From what I can see, there are 3 different choices on how to handle this case:

1. A trailing base type "resets" any previous build process. Here, these two expressions are equivalent:
   Builder().cubano().with_milk(1.0).americano()
Builder().americano()

2. A trailing base type simply adds its attributes to the existing build proceess. Here the expression
   Builder().cubano().with_milk(1.0).americano()
   simply adds the base 0.5 of the "americano" to the existing ingredients, resulting in a coffee with 1 brown sugar (cubano) and 2 milks, 1.0 (with_milk) and 0.5 (americano)

3. Any base type following the first base type call is invalid. So as not to introduce error handling into this kata, any trailing base type call would simply be ignored as a no-op. These two expressions are equivalent:
   Builder().cubano().with_milk(1.0).americano().with_sugar("Stevia")
Builder().cubano().with_milk(1.0).with_sugar("Stevia")

Option #2 is what the reference implementations (and most user solutions) do in C# and Rust, and I assume in other languages as well, however this is purely incidental. When authoring my own solution, I wasn't aware the tests simply wouldn't produce such cases, and opted to go with option #1 for lack of any specification.

Additionally, the spec does not mention the behaviour of first adding milk/sugar, and then calling a base type: Builder().with_milk().americano(). This needs the same considerations as above.

My proposal would be to actually decide on a proper spec, describe it, and modify existing translations to implement and test them while there are only 3-4 languages currently implemented.

Python translation ready for review (see notes in translation discourse)

thanks for kata,it was good one

Nice change from the standard kata.

Well, this is kinda a duh moment for me... I did an iteration version which is wildly unnecessary, if you see this one. If anyone is still wondering how it works, it uses integer division to round down to the nearest whole number before multiplying by the divisor to get the complement.

Should be updated to Rust 1.49.

this doesnt seem to work on a calculator

C# translation. Please, review and approve (the author may be inactive).