Understand the Question

00:00 Okay, so we had a first impression of the code before, and now let’s take a first look at the question itself. Maybe you can give us your thoughts there, Martin.

00:13 I think the person asking the question actually prepared this part quite well. The question is part of the file, it’s up top, it’s nicely formatted, it’s easily readable, and also like this overall presentation of you have the question on top and then the code right under is a nice way to go. It makes it pretty accessible.

00:31 I just need to copy this whole thing and have everything that I need in view basically. And then also when I read over the question, I think it’s quite well formulated. Let’s read it out.

00:41 “How can I make sure that the exception messages of Exceptions that occur in the sub-function load_models show up in the stack trace of the main function predict_raw?”.

00:51 So they’re even doing things like using backticks from Markdown syntax to indicate that they’re talking about a function here, which is not going to render in a Python code comment, but still, if you’re used to writing Markdown, it’s still going to help you have a quick visual idea that this is a function that they’re talking about. And yeah, I think the question is well formulated overall. I don’t have much to say about it.

01:12 I guess maybe there’s some terminology that could be improved. Like here they’re talking about a sub-function and then a main function, which I guess isn’t really such a thing in Python.

01:25 Those are both equal functions here, load_model and predict_raw. And there’s just, you have a caller function—in this case that would be predict_raw—that calls another function, and that’s the called function. Here that’s load_model.

01:39 So those might be better terms to use in here than than sub-function and main function, but it’s still understandable what they’re asking about. So I think the question overall is good. Yeah, maybe the names of the functions is something that we’re going to get back to in the refactoring.

01:55 They could be a little bit more generic. predict_raw, for example. Here it’s more confusing to me than helpful that this function here is called predict_raw.

02:04 That seems like a leftover from the codebase that the person could have refactored out before actually posting this question, I would say. And I think that’s something that we’re going to do pretty soon. Yeah.

02:14 What about right away? Yeah, I mean let’s tackle this one right here. So how would you name predict_raw then to update the question with a correct function name?

02:24 I would just call this the main() function, I guess. So I’m just going to say

02:29 this is the main() function, which is also like how the person described it here. Let’s just call it main() because that this just a generic term of “this is going be the main function that’s going to call some other functions too.” And calling this function main() is just the convention, but most Python developers are going to know what you’re talking about when you name it like that. Exactly.

02:51 And you just did something very interesting as well, which I think improves the question a little bit. You put the parentheses behind main and I think you can do the same with load_models() in line 2 at the end. Nice. Yeah. And we’re going to fix a little typo.

03:06 Oh, true. It looks like it’s load_model() in line 7 where the function gets defined. So yeah. That’s a very good spot. Yeah, because with those parentheses, if you show this to another Python developer, they will see right away, “Okay, so it’s about the callable right there,” while without them, it could be a variable name as well.

03:27 So this is kind of giving a a little visual hint to your code as well, and everything that’s helping your helper is helping you in the end. So that’s a good thing. Lots of help in there. Lots of help, yeah, because that’s what’s what it’s about, right? Like you want help.

03:43 Which brings me to another point of this question before we wrap this up. One thing where you should be clear about is when you post a question online is what is the kind of help you want to have.

03:57 And there could be two things that come into my mind. So, one is you have a problem and you just want to have a solution to your problem, basically fixing your code. What can you do to fix your code?

04:08 And the other thing is to understand why your code isn’t working. And this might be different things. So, in the second case, you might not want to have a fixed code. You want to fix it on your own later, but you want to understand why it’s not working.

04:24 And the keywords here are how and why. If you state your question with a how at the beginning, you probably are looking for help in how to fix your code.

04:37 You want to ideally have a person giving you an explanation of what changes you need to do to make it work, or maybe even some code examples, but maybe you don’t want to know so much about the why behind it.

04:52 And this would be for the second part, if you start a question with a why, you might not be interested in actual code fixes, but more understanding the underneath. In this case, we have a how, so this brings us to the next section of like, yeah, how can we make this work? Let’s start to actually do some changes to the code, right?

05:14 Exactly.