I verbalized the code in my head out loud, then asked how we’d convert the types of the function return value to string before appending ”, meow” to it. Gilch suggested f”{foo(x, y)}, meow” and we had our third decorator.
We then applied decorators in different orders to show that multiple decorators were allowed, and that the order of decorators decided the order of application.
That’s not the order I remember. I recall you tried foo(x, y) + ", meow" first, as I expected from how I worded the task. You tried applying the decorators in a different order for add than you did for subtract, I think because you expected one of them to be a type error, but weren’t sure which. That the order of the decorators can matter and what order they apply were points I was trying to illustrate with this task.
After that, I pointed out the f-string would work even if foo doesn’t return a string, and that would make the @convert_to_str redundant, instead of necessary as an adapter.
Thanks for pointing this out, you’re right. Even when I have your half of the transcript available to me, I still found it sometimes hard to recall what exactly I tried when I was confused about a concept.
That’s not the order I remember. I recall you tried
foo(x, y) + ", meow"
first, as I expected from how I worded the task. You tried applying the decorators in a different order for add than you did for subtract, I think because you expected one of them to be a type error, but weren’t sure which. That the order of the decorators can matter and what order they apply were points I was trying to illustrate with this task.After that, I pointed out the f-string would work even if foo doesn’t return a string, and that would make the
@convert_to_str
redundant, instead of necessary as an adapter.Thanks for pointing this out, you’re right. Even when I have your half of the transcript available to me, I still found it sometimes hard to recall what exactly I tried when I was confused about a concept.