Well, have you considered an actual class?  If you're near a college, you can almost certainly find something introductory, and the knowledge will transfer.
The typical starting assignments for any language tend to go something like this:
- Print "hello world" in a console.
- print the numbers 1 to 10 in the console.
- Print the numbers 1 to 10 in the console, but only if the number is even (hint: number/2 == 0 is the needed condition)
- Build a guessing game that repeatedly asks for a number until you enter the right one.
- Modify the guessing game to tell you if the number you entered is too low or too high.
- Stop and carefully consider how you can beat the proceeding guessing game for the numbers between 1 and 1000 in somewhere around 5 turns.
The last one is particularly important, as the most efficient strategy for beating such a guessing game is pretty trivial once you know it and happens to also be at the bottom of a bunch of important concepts.
This is the pretty typical path.  After that, it'll start varying depending on where/who you're learning from, but the getting starteds all seem to be along those lines.  If you're in a computer science curriculum, they'll start heading for data structures after that--things like linked lists and trees.  But they won't get there for a while because they're going to teach the basics of classes first, and those aren't really enough for you to make the jump on your own.
You want a book.  I've never met a new programmer who can learn from manuals, ever.  I can't recommend one from personal experience.  I can learn from manuals and consequently haven't seriously considered using a book to learn a programming language in years; you will get there if you stick with it, and then you will have the same problem recommending tutorials to new programmers.  I have heard good things from multiple people about Learn Python the Hard Way.  It seems to be using an exercise approach, which seems to also be what you're asking for.
Purebasic or BGT will get you from nothing to playing a sound faster than Python.  I believe that Python has more to offer in the long run.  Frastlin has a project that tries to give some of the BGt convenience to Python.  I have no idea on the status of it, so maybe he can comment.  Whenever Libaudioverse is actually ready, the first language it's going to support is Python; the test project I'm currently working on, basically Shades of Doom but possibly with multiplayer and definitely things like terrain types is also Python.  Python has Pyglet which is nice in a lot of ways which will become clear as you continue to learn programming.
Hope this helps at least a bit.

When I was starting out, I did a lot of copy-editing from small examples, and stuck to the syntax as closely as possible. (To this day, I am in the habit of spacing my switch statements because of those early Javascript examples...)

It was after about 3 months of playing with examples before I made this (I'm not sure of the exact date; I did fix some bugs shortly after putting it online).
To make something similar in Python, all you'd need are:
print
if
elif
else
while
variables
math basics
random numbers
comparing strings (the dinky game I made only checks for equivalence)

There is a bit of terrible coding in there that would have been much improved had I had a grasp of functions at the time.

I drew upon maybe 3 examples for that program. They look kinda like this when translated to Python:

import random

act="-"
password="potato"

# This is the weirdest looking part. You can literally just copy/paste it and change the numbers/indentation if memorizing the syntax is too much at first:
num=random.randint(1, 5)

if num==1 : password="ball"
elif num==4 : password="death"

while act!=password :
    act=raw_input("Enter password:")
    if act=="hint" :
        print "The password is either potato, ball, or death."
    elif act!=password :
        print "Invalid password!"
    else :
        print "Correct!"
    
print "Welcome!"
print "\n\n" # \n is a line break.
print "Goodbye."

I typed this into this post, then remembered I should check it for errors, so I pasted it into a file called password.py. password.py appears to work as expected.

It might not seem like much, but I was never one to ignore an opportunity to make games just because it wasn't as advanced as what the Playstation Developers were using. It was a few months after that text-based fighter before I started playing with a game with keyboard controls, timers, and sound. About a year later, I could probably have handled the bulk of what went into Sengoku Jidai. 2 years in, I would have thought of Sengoku Jidai as poorly coded (because it is ).

I mention the timeframes because I feel like there are two things going wrong, expectation-wise: people with experience tend to expect games to take longer to develop than they strictly have to (better pessimism than optimism, though), while newbies tend to expect to dive write in and start making Skyrim after a month or so. I want to make the next Mainstream quality game as badly as the next person, but I want to make something more than I want to make something perfect. (And that's where baby DLEs come from.)

Woops Camlorn sorry about that lol. After you mentioned it I just assumed it was a paid version. I know stupid right?
Thanks for pointing that out after I saw your link I went to amazon to find the book and it was almost $30 and I checked bookshare and bard again and there was nothing.
Thank you for this I will start reading and working on this today. I'm very glad python has idle since I can test code in real-time. Btw, I have a newbie question what is the difference between idle and the python command line?
I probably should have known better than to get a programming book from bookshare but I was desperate at the time. You know if you have bookshare you should get the book learning python and you could see what I mean. One of the first code examples I saw in that book looked like this, print(`hello world`) but then I also saw the same example like this, print    `hello world` the second version I tried at the time worked fine the bookshare version did not. A long time ago I also found a python book meant for kids that would show you how to create games but I ran into the same problem parentheses instead of indentation but this might have been because I translated it from pdf into text.
If I ever get the hang of programming I'm going to write or record extremely easy and detailed tutorials so that other newbies won't run into the same problems I'm having.
@Cae, thank you for the advice and the code example. I've done the whole copy and paste thing before but when I do that I feel like I'm not doing any actual work. I will probably start copying things to see how they work and then trying to add to them.

Well I've started reading the python book and it's very easy to understand so far. I do have a question though I saw the first code examples which just print text to the screen. I haven't written them out yet but I noticed that after typing print there is no indentation before writing hello world. Is this okay because I've seen an example where it is indented after you write print.

Hey Camlorn.
Yeah your right I'll just start from scratch. I do have one more question it says in the book to use python 2 which is what I have on my computer sometimes it says python 2.7 but I've seen a couple of times where says python 2.6. I have python 2.7.9 which I assume is the proper one to use. So am I right or wrong?
Anyway camlorn I just wanted to say thank you for helping me and answering all my newbie questions.

@Guitarman
2.7.9 is fine.  There are no major incompatibility issues unless you go to 3.  Almost no one is on 3 for something real, though we might be headed that way in a year or two.
@Alan
The comments about IDEs are true if you are sighted.  Modern versions of Visual Studio are not accessible to the point of being convenient, though you can use them if you are on Jaws or possibly Window-eyes.  You still have issues, though.  If you aren't, all the debugger windows do not work at all.  Idle is not accessible, at least with NVDA.  Pycharm and anything else by IntelliJ?  Not accessible.  The tools that a blind person could benefit from include autocomplete and debugging.  Everything else---all the parts sighted people like to do with color and all that?  They don't pertain.  There is a possible argument for automatic formatting, but you can get that in your text editor anyway or just run your stuff through a command line program.
I know and  have known quite a few programmers working in the professional workplace who all use the command line, and many of them are younger than me (18-19 age range).  I have it on good authority that Amazon uses command line development for Android app development, though this is word of mouth and consequently I don't have something to site here.  As soon as you start something that is client and server, i.e. basically all of industry, you're going to need the command line for lots of stuff.  The biggest C++ projects in the world tend not to use IDEs either, most notably llvm which uses Cmake.  Many big projects like PostgreSQL are accessed through the command line and configuration files, too.  The only people who try really hard to force the IDE are those who wish to lock you to a platform, at least in so far as I have seen.  The command line approach lets you go lots of places because it's mostly the same, but learning an IDE makes it very hard to leave that IDE, so god help you if it's in any way platform specific.  There are also some indications that microsoft has begun to realize this, as well: one of the demos my uncle attended in his role as manager of a big MS stack web company had Microsoft being excited to show off that you can use any editor you want with their new stuff that now runs on Linux, and Windows 10 has reworked the command prompt entirely to give better editing.
You're also wrong about Python.  I'm not going to claim that one language is "best", but I'm not going to allow misinformation either.  C# is not popular in this community.  I think there's like 2 or 3 finished projects in it.  Python and C# are about the same, though, if you go outside it.  The truth is that a majority of games for the sighted are written in C++ and using something else is niche no matter what it happens to be.  Wx is an accessible GUI library with examples, Pyglet is an accessible keyboard/mouse/graphics/sound library with good tutorials, and Pygame is incredibly popular for teaching new programmers game programming and has more documentation than the proceeding two combined.  C# game tutorials normally start by having you instal something else; this is typically SlimDX or XNA, as I recall from when I did my C# time.
There is one fast way to audiogames.  This is BGT.  It will jump-start you in that you can get sound working, but the only source of documentation you have is BGT's manual itself, and you'll leave once your project gets big enough.  Outside that, it's equally difficult to get keyboard and sound working in everything.  It is true that C# will give you access to windows messages pretty quickly, but no one works at that level; in addition, "pip install pyglet" at a terminal is equivalent to like 10 steps in Visual Studio, and I need only run it once, ever.  It is true that I had to post the other thread about Pyglet recently, but things like that particular issue can happen in any language; I'm sure something like it exists in C#.
And I'm not sure how .net is higher level than Python.  .net seems to be about the same.  I'm thinking you don't actually know Python.  Most Python concepts have an equivalent C# concept, and most C# concepts an equivalent Python one.  Most of the things that are left have to do with core philosophy: whether to be statically or dynamically typed.

Okay.  Well, I'm going to assume you're using Visual Studio 2008 with jaws.  Debugging does not work with NVDA.  Debugging never has.  After I managed to fight multiple inaccessible parts of submitting a bug report and including specifically what isn't working and how they can fix it, Microsoft's response was "we know, we can't get it into the next release", but it's been a problem for as far back as I went.  If youa re only stepping by line, you can.  But doing simple things like looking at variable values requires workarounds at best.  2010 and 2012 broke very basic things, though 2013 fixed some of them.  Autocomplete has never worked well, if at all.  Alt-tabbing doesn't work as soon as you use one of the high contrast color schemes (no, I don't know why, and if you had asked me I'd have said it was impossible to break it in this way).  Formatting information is not available.  Autocomplete might work, but by the time I'm done dealing with all the other problems I've honestly stopped caring, and autocomplete isn't a big deal anyway.  The only IDE that rates as fully accessible is Eclipse, and even there NVDA requires at least one workaround.
For C++, I use CMake for building and cdb for debugging, though I will admit that cdb is somewhat cryptic until you learn it some.  Most languages  have command line debuggers, with c# being a rare exception.  That said, cdb may work on it-I've not had occasion to try.
The way you manage resources in a sane world is to stick them in the directory structure.  You don't need Visual Studio to do this for you.  If you are using one of the custom formats like xnb, you should know that that's an incredibly awful thing.  And if you aren't, then VS is literally just copying a file on your behalf, and you can do it in even less time in Windows explorer by typing paths in the address bar.  All of my projects have a little snippet of code that knows how to find the sounds directory and give me a sound object in whatever audio system I'm using, and I add new resources simply by putting the new file in that directory.  The idea of the project as separate from the directory is completely false.
In terms of building C#, there's basically 0 compile time-you can get away without incremental building for a project the size of an audiogame.  Failing that, you can use nmake or gnu make on them just fine.  The only times you need MSBuild is if your project needs WPF or is targeting WinRT.  99% of games don't need either of these.
You've tied yourself to VS.  Judging by other posts, you are a new programmer.  This is therefore not surprising.  Unfortunately, as a blind person, that's not optimal.  It may be about the same if you take the time to memorize keystrokes to get around accessibility issues, but the whole point of an IDE is that you can glance at things.  And we can't.  I think that in the sighted world IDEs serve three purposes: GUI designers, crutches for new programmers, and a system for quickly presenting information to a user who can move their attention at literally a thought.  GUI designers don't apply.  Crutch kind of does because you can avoid the command line for a little while longer.  Our method of moving our attention is to use multiple keystrokes and basically completely switch from what we're doing to something else, presuming that the part of the IDE we want is accessible in the first place.  I have toyed with the idea of making an IDE or at least a text editor aimed at the blind, but this just isn't worth the effort; if I did, I think I could do some nice things that would actually bring some of the benefit to us, but it'd almost certainly need to be self voicing.
Unless you're partially sighted, GUI design isn't something you will be able to do effectively.  That said, those lists are just method calls, and if you actually learn them instead of using the editors you can go faster.  Navigating huge lists of hundreds of items is not a fast way to write anything.   Wx does not give you an editor like that, but you can still make the method calls.  There's also an abstraction aimed at the blind called gui_builder, but it's undocumented and a new Python programmer isn't going to be able to figure it out without docs.  That aside, though, at least half of audiogames don't use GUI components, and most games in general need a completely different structure than a GUI provides anyway.
I'm assuming you're somewhat new to programming as we had the Screen Reader API thread.  As you learn to program more, your ability to memorize things and not need the features you're leaning on will go away.  I think the dependence will go away even faster if you choose to explicitly work on it.  Most libraries and components are well written so that you can guess the name of something, or at least so that once you know the name it's kind of obvious why it is called what it is.  I don't know what common code snippets are.  The only thing I can think of is a for loop header.  Everything else needs customization, and by the time you're done customizing you should probably have just typed it to start with.  If you realy need project templates, set up a project somewhere and copy its directory.
As for who uses command line tools in the sighted community, basically anyone who is not either a Microsoft or Apple shop.  Parts of Android development require it.  Node.js, Python and Ruby all provide everything except autocomplete at the terminal.  This includes getting packages installed and line-by-line debugging.  Linux and OS X make system libraries a first class citizen, and installing them is one command at a terminal in both of those as well.  Go, Rust, Nim, Haskell and D do not have fully featured IDEs to my knowledge.  Of those, D is the only language I can think of an IDE for at all.  LLVM is one of the biggest and most important C/C++ projects and takes something like an hour to fully build.  It does not use an IDE, probably because it outgrew all of them.  Pypy is a very cool project that overturned huge parts of CS by successfully going against a bunch of things that people would have argued were basically facts.  Again, no IDE.  Firefox.  Linux.  Probably windows, judging from what people who have worked at Microsoft have told me.  Anything C/C++ that's supposed to run on Android.  Software for half the microcontrollers and embedded processors on the market.  Most Linux software.  I rest my case, and I haven't even talked about how you get big multidisciplinary teams where standardizing on an IDE can't be done because everyone knows something completely, completely different from everyone else.

And to be completely clear.  I think that a fully accessible and convenient IDE would be a wonderful thing.  My objections are based purely around being blind and having accessibility issues, not around an IDE being a bad idea in general.  If I could be hired to work on it, I'd not mind making one aimed at the blind.  But there's no market, so that'll never happen.
As for Python professionally, yeah, ease of use is probably part of it.  If you know any programming language, you know Python.  It's undeniably big in two areas, however.  The first of these is web, and that probably comes back to the ease of use; also, it's got Django which is a big deal by itself.  The other one is, surprisingly, high-performance numerical computing and, basically, "science".  Python is the most powerful calculator on your system.  It can do all your Algebra 1 and 2 homework and a good bit of your calculus homework with little to no effort.  If only it could also show the work.  Python laughs at DSP, statistics, probability, etc.  Ironically this is because of Numpy, Scipy, and Sympy, all of which come together to give you the power of matlab in a general-purpose programming environment.  The irony is that you could probably write a pretty high-performance physics simulation system in Python by backing onto Numpy and only be 2 or so times slower than C. Also, there's at least one project that can give you a computing cluster ready for your high-performance machine learning project in an afternoon or so of tinkering (if you're wondering, I have a potential thing for Libaudioverse that involves finding "magic" numbers that I might do, so I looked int it).
But since I'm actually more neutral than I appear, I'll also play devil's advocate.  For extremely large systems (100 kloc or so) choosing a statically typed language may be a better choice because the compiler will be able to catch potential issues faster.  Python is incredibly slow in and of itself, and multi-core programming without calling C requires spawning more Python subprocesses.  The Python 2 and Python 3 split is painful, but maybe resolving itself soonish as people continue migrating.   There are some obscure pain points here and there having to do with something called the descriptor.  Python is a memory hog and so, for large datasets, you have to explicitly use packed arrays.  There are 4 ways to bind to C instead of just one, though none of them have much of an advantage and you can just pick the one you like.  Finally, packaging can be a bit painful the first time you do it.
Not that much of that applies to games, though.

You are right about only needing 6 keystrokes, technically.  I would hate to see your productivity, however.  My build is about 3 keystrokes ("jom").  My debugger lets me have everything.  C# doesn't have a good debugger if you're blind and Java may not.  But everything else I'm aware of does.  I have the ability to go line by line and pull out variable info, CPU registers, and contents of specific memory addresses if needed.  I'm almost sure I have watchpoints, but have never once needed this functionality, so I can't tell you.  Again, all of these things are two keystrokes or so plus a name.  In fairness, most of this works in VS with Jaws, to one extent or another, but the sheer amount of time needed to switch from window to window is insane.
As for GUI development, yeah, I suppose there's the sighted person approach.  I don't develop stuff with GUIs.  If I did, I'd do it some myself as I can get far enough that things aren't overlapping, and then ask sighted people to describe what they'd like it to look like.  I suggest looking at system.windows.forms.FlowLayoutPanel and system.windows.forms.TableLayoutPanel.  These are helpful.  most other GUI frameworks have equivalents, and the irony is that the designer starts to fall down hard if you start talking about devices with anywhere from a 5 inch to a 50 inch screen.  Surprisingly enough, as of Windows 10, this appears to be the case.

Py2exe does now work with Python 3.  In fact, the Python 3 version is better, at least looking at the docs: it now supports zipped eggs properly.  There's also cx_freeze and Py2app.
As for Python 3, though, you should really be on 2.  There might be a WX somewhere, but that's only the beginning of your problems.  When they went from 2 to 3, they intentionally broke backward compatibility.  And the backlash and time to migrate was way higher than they wanted it to be.  2 is still seeing active development, just not new features, and it's easier to find backports than it is to find packages for 3.  There are a lot of essential packages that haven't moved yet, so no one really has motivation to port their nonessential packages.
You'd not be missing much by staying on 2, anyway.  New features in 3 are not things that are super helpful for audiogames, and 2 is probably going to be seeing patches and security updates for at least another 5 years.

Guitarman,

If you want someone to bounce questions off of you may add me to skype or twitter. I find that by teaching, I learn as well.

Just let me know if you want to do this and what medium and I'll give you the right ID.

Balliol

@guitarman, I could probably help you in this matter, if you wish.