Finish reading the Python book, then go do C++. The hardest parts of C++ are Object Oriented Programming, pointers, and memory allocation. But if C++ is what you're excited about do that. If it turns out to be too hard for you right now, you can always go back to Python.

But don't just keep hopping from one language to the next before you even finish reading the book on one. In some ways you will find C++ more difficult and in some ways Python will be more difficult. For example, you're probably going to find 10 C++ books for every Python book you can find. One of the most difficult parts of C++, probably even more so that pointers is trying to do something with it more than just text/console programs. C++ is very low level. It's practically Assembly Language. It doesn't "do" much for you. In that way, it's kind of the opposite of Python. You have to do everything yourself with C++, which is good for your education, but difficult.

It's what comes after C++ that is the truly difficult part, because that's where your journey actually begins. Your C++ book may not even cover how to make a window in Windows, let alone how to program in Windows. For Windows 7, you had to learn Win32 or MFC. I'm not really sure exactly what they have going on in Windows 8 & 10 these days. XAML may relieve you of some of that.

Likewise, with games in C++ it's not going to be as simple as in other languages. One of the easier ways is to use a library like SDL which only does 2D games, not 3D. OpenGL is actually not that bad although getting someone to teach it to you may be near impossible. That's what makes OGL so difficult, the lack of good instruction on the subject. Game Institute has a decent OGL set of instructional videos for C++. But I think it's about $100 USD to access pretty much all their content except certification classes for about a year. It think it's actually a pretty good deal. They also have instructional videos on DirectX and Unreal Engine (which uses C++).

DirectX is difficult largely because it is a COM object as in Distributed COM. Although, you really don't have to learn much COM or Win32 to do DX. You have to learn enough Win32 to ask Windows for a process and ask it for a Window to draw in. And the only thing you really have to know about COM is that you can't deallocate like using new and delete in C++; it keep track of how many instances of the COM object there are (in this case probably only 1) and you tell it you are done with it and it marks that one off the list and destroys itself when you tell it you are done with the last one. Other than that, all you need to know about COM is that it uses redirected pointers which are some of the most difficult pointers to understand. So, get ready to really know pointers if you are going to do DirectX. Those things make it substantially more difficult than OpenGL.

Vulkan and DX12 are especially difficult. For DX12, you have all the previous issues plus now it's doing everything at a lower level and pretty much putting you in charge of the graphics card functioning which gives you a whole slew of ways to crash your computer. Vulkan's pretty much the same without COM.

But C++ is a good computer language to know. You're getting into the computer at the deepest levels with C++. But learn to use libraries when you can, especially at first. OpenGL with libraries is not to bad. In fact, the hardest part is setting up the libraries like GLFW, GLM, GLEW, and FreeImage. The next hardest part is getting someone to tell you what you're supposed to do with OGL. I'm working on a bare bones 3D game engine for OGL 4.5 right now. The purpose of that is to put the source code for it out on the Internet for everyone to use and learn the basics from. Then to write tutorials that expand on that to help people know what to learn next and really get started.

I already have the bare bones engine written and published for DX11 on my website unofficially. (I'm not sure I quite finished it, but what may be left is mostly cleaning up the code and commenting. It pretty much allows you to make 3D games and load 3D models into the game. It's pretty close to where you'll be at if you go through the Game Institute OpenGL instructional videos when you're done with those.) My intention was to do YouTube videos on where to go from there, but I've switched over to learning OGL and trying to rewrite it in OGL now.

Unreal Engine might be a way to go once you learn C++, although I haven't tried it, and I hear it only does 3D games, not 2D.

C++ is just a long and difficult road, but the road that leads to the deepest understanding. But if that's what you are passionate about, pursue it. Worst case, you get frustrated and go back to Python for a few years until you are ready for C++.

We were taught C and university before C++. If you're interested in C++ i'd start with a bit of C to get used to the general syntax without complicating it with object orient programming. It would still probably be better for you to stick with Python for a bit since you've started. C and C++ are probably not regarded as beginner languages however it is where i started and i came out ok!

I'd stick with Python. You don't want to "language hop" too much, or you just waste your time learning surface-level syntax (how to write code) instead of going deep beneath the surface where the real programming is (how to think about code).

School just started so I checked the library. I was hunting for a Python related book

Use online resources - any book you get would likely be outdated anyway (if it's more than 5 years old), and if you are going to start learning, you'll want to learn the latest python.

But if you know of a modern python book, ask your local non-school library to borrow a copy from their coordinated intra-state library network. I do this from time to time - occasionally it's free, but sometimes (rarely) they charge a couple bucks for shipping (possibly only if they have to borrow it from outside their network - different library networks may differ).

Stick with Python until you finish a few games. Within that few games (after the first ones), try making one that requires you to handle thousands of objects. It will help you scratch your head to learn how to handle the performance issues using practical algorithms exist. Try upgrading your games too to learn how to abstract things out.

Until you get the idea of practical data structures and algorithms and patterns, that's when you'll find yourself easy jumping to another languages when required, cause in the end they're basically the same. It's all about how you handle data. :unsure: