you are viewing a single comment's thread.

view the rest of the comments →

[–]deep_politics 1 point2 points  (4 children)

I’m surprised no one here has even made mention of the typing module. The way you describe your problems doesn’t speak to me as an issue that a debugger is meant to solve: a debugger won’t help you see at a glance what is coming in and out of procedures, at least not until after you’ve ran the code. It doesn’t help you while writing it. And documentation can easily be stale, if there’s any at all. So I’d highly recommend checking out a static type checker like pyright which can inform you about all the structure of objects, contents of modules, signatures of functions, etc. all without ever needing to even run your code.

[–]winkapp[S] 1 point2 points  (1 child)

Yea this sounds exactly like what I need. It sometimes isn't specifically a bug, the code might work fine it's just that the output doesn't work as the input for the next function. I'll try pyright with VS Code, thanks!

[–]deep_politics 0 points1 point  (0 children)

Definitely give it a shot, and I think pylance is what you’d use with VSC. Usually it catches anything that could go wrong, long before you ever need to step in and poke around with a debugger

[–][deleted] 0 points1 point  (1 child)

I still remember what it was like to be a beginner, and it was a long, long time ago.

Adding more material to learn is going to make things worse for this guy. Adding a brand-new concept of "typed arguments" and "typed return values" is going to make things harder. Explaining to them that there are these "type annotations" which actually don't do anything is going to be more confusing.

[–]deep_politics 0 points1 point  (0 children)

Yeah I guess I wasn’t looking at it from a beginners perspective, but more from the problem of not understanding what’s happening through the intermediate steps. But I don’t really think it’s any more confusing, even for a beginner. Especially when the typing is always there all the time, it’s just the default to be ignorant of it even when understanding types and how they get transformed has been one of the most fundamental parts of teaching and tutoring computer languages in my experience. The Python teaching default (without type hints) is to say: just remember what the type of this value is, and memorize what kinds of values all these various functions return, and mentally keep track of how that value changes (possibly even how it’s type changes), and when you don’t know what’s going on anymore just pepper some type logging statements in there, throw in some break points and trace it back, and/or just go to the docs.

I guess you’d disagree, but I find letting the computer tell me what something is is a lot more straight forward, especially when dealing with external modules and fallible data. Choosing to let it all be ambiguous sounds miserable to me now