TicTacToe v002 with improved AI, again i hope it is helpful, the code could be optimized by using...

[G+_Scott B]

TicTacToe v002 with improved AI, again i hope it is helpful, the code could be optimized by using a for loop and a little bit of math, im sorry there are no comments. im sure there are some bugs. i know hate indent errors with a passion :-)

http://pastebin.com/YPTcqjeM

[G+_Lee Crocker]

Whenever your code looks repetitive like this, with large blocks of if/then/else, consider moving the program logic into a data structure. It will make the code smaller, simpler, easier to understand and update. I'll see if I can come up with an example tonight.

[G+_Lee Crocker]

For example, to replace lines 13 - 207 of your program: http://pastebin.com/PnGHH0c6

[G+_Scott B]

its interesting to see the solutions to getting rid of all of the if statements. cool  

[G+_Lee Crocker]

A great principle for programmers is DRY: don't repeat yourself. Computers are great at doing repetitive tasks; it's your job to design the data structures and algorithms so that it can do the repetitive work and you don't have to.

[G+_L I]

Nice - even cleaner than my approach

[G+_Darryl Medley]

Single test function version: http://pastebin.com/L5VqxD5h

After seeing Lee's brilliant "wins" list I noticed that both test functions are looping over the potential win paths and it would be a fun exercise to combine them into a single function for even more consolidation. I don't think this way is any better because it probably has more overhead. I'm simply posting it as an example of another way of doing it and also to show Python's powerful "list comprehensions" and "generators" because they probably won't get covered in the show.

[G+_Lee Crocker]

That's one of the problems with Python; there are lots of interesting and fun features to use that may or may not make your code better. :-)?

[G+_Scott B]

i used the two loop using the range() command for the tests but decide to post the code using if else. i know its not the best practices   but it is easier to read for a beginner than a nested command, i was quite impressed with both of the examples and i am sure they will help people understanding lists.

[G+_L I]

There really is a delicate balance between making your code real tight and efficient and keeping it understandable for the people who will review/inherit it

[G+_Nevrin O]

noticed an error in your program

random.randrange(1,9)

this will only pick numbers 1,2,3,4,5,6,7,8

meaning the computer will never randomly pick 9

it can still mark 9 if its trying to block or win and because player 1 always goes first you cant make 9 the only spot left for computer to pick randomly but if you do change it to alternate turns it can cause an endless 'print "the move was invalid or space has been taken" ' loop

The only problem with it in its current implementation is that you can use it for a unfair advantage, but since its a computer that just picks randomly its not much of an advantage anyway.  just thought you should know.

[G+_Scott B]

nice spot, the first version used bord[] 0-8 v002 uses board[] 1-9. i didt change the random to reflect this, i was going to use board[9] (board[0] in v002) to skip the name input if a game had been played.

[G+_L I]

Darryl Medley question about your implementation: I notice you use "list comprehension" and "generators" - I've just read up on what they are and they seem very powerful. Am I correct in saying that they both do essentially the same thing but the list comprehension is for when you want to keep the list, but the generator is for when you want to use it only to feed another function/statement?

[G+_Lee Crocker]

There are no generators in this code. Your impression of their use is pretty good, though. Comprehensions are a handy syntax for filling a list with a short piece of code. Generators are for producing sequences on-the fly that may not even fit in memory, or whose values may not be knowable until they are produced.

[G+_Darryl Medley]

I found that "next" code online. I understood that the expressing inside of the next function, ((idx for idx, mrk in enumerate(boardMarks) if mrk != mark1)), is a "generator expression" but if it's not then I'm sorry for the misnomer. Lionel, The way I understand it is that list comprehensions are shorthand for quickly processing a list while generators spit out one value at a time like when next() is called but I'm new to this stuff as well so my understanding is limited.

[G+_L I]

Lee Crocker I was under the impression that a double parentheses meant a generator and the braces meant comprehension:

 

return w[next((idx for idx, mrk in enumerate(boardMarks) if mrk != mark1))]

 

I've been playing around with the comprehensions on some of my old code and find that it comes in very handy and reduces a lot of code in some cases. But I'm sure I'm probably overusing it now :)

[G+_Lee Crocker]

Looking at the docs, it appears they do use the term "generator expression" for those. I tend to reserve that term for the object returned by a function with `yield`.