Kata

This kata requires you to use a specific language feature - either you know it, and the task is very simple, or you don't know it, and the task is (probably) impossible to solve. I don't know what you have tried already, but at least your current solution is wrong, and without changing the approach you won't achieve anything.

Doesn't help that some very key information only exists in the "BTW NOTE" as opposed to being part of the actual description of what's to happen.

I would much rather receive predicates and return values that exhibit the described behaviour, but I guess if one takes away the OOP from an OOP design pattern it's no longer difficult enough that anyone would think it needs a name XD

by investigating further, you're doing stuff through some other method, with the classes you're defining. That's pretty unusual. That's not specified.

"Instead, you should implement a much more beautiful specification pattern by getting rid of those annoying class instantiations" - the description says you're not supposed to instantiate anything (it may not be clear that this rule also applies to the imlemented class/metaclass, so I agree that this could be mentioned), so using __init__ is incorrect (point #2). As you can't initialize any Specification, defining __bool__ achieves nothing (point #1). The only way to make Specification(value) behave as a boolean is to make it an actual boolean, and I think there's only 1 way to do so (point #4). I can add a note that calling the specification-class should return a boolean, but I'm not sure whether that will be of much help, and figuring all this stuff out is supposed to be a part of the task (point #3), so providing more details would spoil it.

Mmmmh, I don't see all of that this way.

"you" could still build all the constraints the way you currently do it and when the call is done with the arguments, you perfectly can build the actual instance, with a __bool__ method that will do the work for the condition. I see what you said about "getting rid of the instanciations", but imo, you took this too far. I mean: This is about OOP patterns, right? Though you have no instances anywhere, currently.
Moreover, about OOP, what you currently do is an antipattern: using an instanciation syntax, like Drink(stuff) or (... & ...)(stuff), that returns something else than an object actually inheriting from Specification is... an antipattern, as I said (to me, at least).

Note that with what I suggest, you still actually get rid of all instanciations, except the last one (I mean: on the user side. What's happening under the hood isn't his problem). So that doesn't change the interface, just the way it works. And about OOP pattern, this is imo more consistent because if you get in the end an actual instance, you can add new behaviors on it. Like, add methods __add__ and __radd__ and you could compute the cost of the resulting class at the same time (you sort of mix your approach with a decorator pattern).

In my mind, if you work with OOP design, you need to end up with actual objects/instances. Am I clear enough?

EDIT: might be somehting isn't clear enough about the way I see the problem: for now, my approach is to build intermediate classes on the fly. So Hot & Dink is building a HotAndDrink class, that can be instantiated with (Hot & Dink)(stuff). Are we on the same page about that?

using an instanciation syntax that returns something else than an object actually inheriting from Specification is... an antipattern

That's an opinion. It might be a weird choice to do so, but it's a valid and documented language feature, and I don't see anything bad in using it.

you still actually get rid of all instanciations, except the last one... this is imo more consistent because if you get in the end an actual instance, you can add new behaviors on it

But I want no instances! :angry: The argument about additional behavior is irrelevant. It doesn't have to be expandable or follow some state-of-the-art software architecture design, because there is no architecture - you're supposed to implement 1 very specific feature with very specific behavior, and nothing more.

Of course, the current test setup enforces a specific implementation, but that's exactly the point: there's an additional challenge of making Specification a boolean instead of just imitating it, and I won't to keep it this way. If the intent is not clear, as I said, I can add a note about how it should work.

okay, but you need to add that at the end too:

...but return True/False itself, just like Drink(drink) and the other base classes extending Specification will do.

Without that, you're still hiding the "base" of the mechanics

The problem is that I'm working with the classes directly while you're ignoring this fact and creating instances. The only hint I can give is that the built-in method for creating instances can be used as a predicate.

Edit:

To do so you have to create a class Specification which will be inherited by other classes

Your solution works only as long as you yourself create all the classes for the Specification pattern. Obviously, this won't work when all the setup is performed in the tests.