A Beginners Guide to Python/__25. Design Decisions, How to Build Chess Game.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Features of Good Design\n",
    "\n",
    "Hi guys, this lecture is a bit different, today we are mostly glossing over Python itself and instead we are going to be talk about software development. \n",
    "\n",
    "At this moment in time you are writing tiny programs, programs that in many cases are ten lines (or less) long. And let me tell you, when try your hand at writing programs two, or three-thousand lines long you will quickly learn that not only is it significantly harder to get it working, you will also find **the skills you need change as well**. For small problems, knowledge of  syntax and language semantics are often sufficient and concepts like ‘readability’ can even be ignored (although you shouldn’t). However, if you try to scale up and write something over weeks and months you will likely find your casual disregard for readability ends up biting you. And similarly, if you jumped ‘straight-in’ without considering the ‘bigger picture’ chances are you will end up rewriting a lot of code as you start to realise, weeks later, that the current implementation is not scalable, or something. \n",
    "\n",
    "Today’s lecture is intended as a introduction to some of skills you will likely need once you try to develop a substantial (e.g 300+ line) programs. **The TLDR version; figuring out a good design ‘off the bat’ can potentially save you hours upon hours of work later on down the line.** \n",
    "\n",
    "Today I will be showing you an example of how we might code up a game of chess. But crucially I’m going to skip over a lot of the ‘low-level’ stuff and instead try to provide a ‘high-level’ sketch for what such a program may look like.  On that note, when reading today’s code please consider it a ‘rough sketch’ rather than definitive, if you look at it with a magnifying glass it will collapse like a house of cards. But as I say, today is all about the bigger picture, or  ‘high-level’ thinking. \n",
    "\n",
    "There is a saying in England:\n",
    "\n",
    ">“[you] can’t see the forest for the trees”*. \n",
    "\n",
    "It means that if you examine something closely (i.e. each tree) you might miss the bigger picture (i.e. that all the trees come together to make a forest). Well, all of the lectures in this series have been talking about trees, and now we are talking about the forest. \n",
    "\n",
    "## What is good design?\n",
    "\n",
    "So before we start looking at a chess game lets say a few words about design; in particular, what counts as good program design?\n",
    "\n",
    "#### Simplicity\n",
    "\n",
    "    Simple is better than complex.\n",
    "    Complex is better than complicated.\n",
    "    [...]\n",
    "    If the implementation is hard to explain, it's a bad idea.\n",
    "    If the implementation is easy to explain, it may be a good idea.\n",
    "    \n",
    "As always, Tim Peter's ‘Zen of Python’ has a thing or two to say about design, the lines highlighted here place an emphasis on simplicity and clarity of expression, these concepts are core to the entire language and we would do well to remember that;  if things start to get complicated maybe it would be prudent to take a step back and reconsider our approach. \n",
    "\n",
    "#### Performance\n",
    "\n",
    "At first glance we might think performance is a 'low-level' consideration. You write something and then find ways to saving a byte of memory here or there. But considering performance merely as ‘fine-tuning’ would be a crucial mistake. \n",
    "\n",
    "Those of you that watched my 'joy of fast cars' lecture would have seen a few examples of such low-level 'fine tuning', in one example I showed how we could optimize a call to range such that we could search for prime numbers faster. And for what it is worth this tinkering did in fact pay off, we were able to lower the time taken from ten seconds to three seconds, our tweaking resulted in a performance boost upwards of 66%.\n",
    "\n",
    "However, that lecture also contained a ‘high-level’ idea as well; our tinkering with the range function was, although faster, still blindly searching for *a needle in a haystack*. We then stepped back and wondered if there was a better way to do it; and with a little help from Google we found a way to *generate* primes efficiently rather than *searching* for them in a sea of non-primes. And the algorithm we found to was over twenty times faster than what we could with ‘low-level’ tinkering. \n",
    "\n",
    "The lesson here is that good design choices, even if executed poorly, can easily out-perform bad ideas implemented well. If you want to know more about this, please check do some reading on [‘algorithmic complexity’](https://en.wikipedia.org/wiki/Analysis_of_algorithms) and Big(O) notation (we wont cover this stuff in this course).\n",
    "\n",
    "In short, good design/algorithm choices tend to be very performant once we scale up the problem to huge data sets, and this is why its worth taking the time to come up with a good idea.\n",
    "\n",
    "#### Generalisable / Reusable\n",
    "\n",
    "Writing good code once and then reusing it is often better than starting from scratch each time. The way to make code reusable is to generalise it to solve variety of problems. This concept is probably best understood by example. \n",
    "\n",
    "Suppose we were making a function that counted *1-to-100*. What can we use this for other than its intended purpose? \n",
    "\n",
    "Now suppose we write a function that counts from *n-to-m*. This code works for the current problem but because its design is generalised we may be able to reuse this code at a later date, in this project or the next. "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 1,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "# One use, \"throw away\" code:\n",
    "def one_to_one_hundred():\n",
    "    for i in range(1, 101):\n",
    "        print (i)\n",
    "        \n",
    "# Multi use, 'generalised' code:\n",
    "def n_to_x(n, m):\n",
    "    for i in range(n, m+1):\n",
    "        print(i)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "#### Beauty\n",
    "\n",
    "> *Beautiful is better than ugly.*  \n",
    "Tim Peters, ‘Zen of Python’\n",
    "\n",
    "Beauty!? At first glance making beauty a consideration my sound like a strange or 'out-of-place' concept. But if you take a broad view of human achievement you’ll find that we mere mortals make things, and then make those things beautiful.  Just think of something like a sword, its an object made with the most brutal of applications in mind and yet we still decided that this was an object worthy of being made beautiful. \n",
    "\n",
    "Another discipline where discussions of aesthetics may initially seem out-of-place is mathematics, and yet, there are no shortage of mathematicians throughout the ages  discussing the [aesthetic qualities of field](http://www.huffingtonpost.com/david-h-bailey/why-mathematics-matters_b_4794617.html) and moreover there is some [experimental evidence](http://www.bbc.co.uk/news/science-environment-26151062) to suggest mathematicians genuinely see beauty in formula's in the same way the rest of us see beauty in music or art. For some, beauty truly is the joy of mathematics.\n",
    "\n",
    "> *\"Why are numbers beautiful? It's like asking why is Beethoven's Ninth Symphony beautiful. If you don't see why, someone can't tell you.\"*\n",
    "Paul Erdos\n",
    "\n",
    "I think it would be wrong to dismiss beauty as a trivial aspect of mathematics or programming for that matter.  There truly is a joy in experiencing good code, you just need to learn to appreciate it, I guess. \n",
    "\n",
    "## Building a Chess Program...\n",
    "\n",
    "The above discussion highlighted a few aspirations we should have when trying to come up with a solution to this problem; the more beautiful, generalisable, perfomant we can make our code the better. \n",
    "\n",
    "Before we start coding, lets type out a list of things we need to do:\n",
    "\n",
    "1. Represent the board (8x8 grid, alternating black/white squares)\n",
    "1. Define piece movement, capture rules.\n",
    "1. Define all other rules (e.g. promotion, castling, checkmate, 3-fold repetition, etc)\n",
    "1. Peripherals (e.g. clocks, GUI's, multi-player features like match-making, etc)\n",
    "\n",
    "Thats a lot of stuff to do right there, today's lecture will mostly deal with points one & two.\n",
    "\n",
    "### Building the board\n",
    "\n",
    "How should we represent a board in Python? This question mostly just reduces to what data-type we should use. Right now, I have two candidates in mind; strings and lists. \n",
    "\n",
    "We could of course jump ‘straight-in’, pick one the data types at random and see what happens but, as alluded to in the above discussions such a method is both silly and wasteful. A better use of time would be to carefully consider our options BEFORE we write even a single line of code.\n",
    "\n",
    "#### The Board as a string\n",
    "\n",
    "Okay, so let’s consider using a string for the board. What might that look like?\n",
    "\n",
    "Well, the letters \"QKPN\" could represent the pieces (lower-case for white), and we could use the new-line escape character (\"\\\\n\") to separate the rows. Something like this:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 2,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "RNBQKBNR\n",
      "PPPPPPPP\n",
      "-x-x-x-x\n",
      "x-x-x-x-\n",
      "-x-x-x-x\n",
      "pppppppp\n",
      "rnbkqbnr\n"
     ]
    }
   ],
   "source": [
    "print(\"RNBQKBNR\\nPPPPPPPP\\n-x-x-x-x\\nx-x-x-x-\\n-x-x-x-x\\npppppppp\\nrnbkqbnr\") # 'x' and '-' represent black and white."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Actually, we can do even better than this, Python strings support unicode and there are [unicode characters for chessmen](https://en.wikipedia.org/wiki/Chess_symbols_in_Unicode#Unicode_codepoints_and_HTML). So now our string implementation even comes with some basic graphics:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 3,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "♙♙♙♙♙♙♙♙\n",
      "♖♘♗♔♕♗♘♖\n",
      "\n"
     ]
    }
   ],
   "source": [
    "print(\"♙♙♙♙♙♙♙♙\\n♖♘♗♔♕♗♘♖\\n\")"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Okay so the board as a string seems possible, but are there any drawbacks of an implementation like this? Well, remember that strings are an *immutable data-type*, which means that every time we want to change the board we have to make a new one. Not only would this be computationally inefficient it may also be a bit ‘fiddly’ to actually change the board.\n",
    "\n",
    "For example, lets see what sort of work we would have to to make the move 1.Nf3:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 4,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "RNBQKBNR\n",
      "PPPPPPPP\n",
      "-x-x-x-x\n",
      "x-x-x-x-\n",
      "-x-x-n-x\n",
      "pppppppp\n",
      "rnbkqb-r\n"
     ]
    }
   ],
   "source": [
    "def make_move(move):\n",
    "    \"\"\"Takes a string a returns a new string with the specified move\"\"\"\n",
    "    # Code here\n",
    "    pass\n",
    "\n",
    "# Our new function would have to take the original string and return the new string (both below)...\n",
    "original_string = \"RNBQKBNR\\nPPPPPPPP\\n-x-x-x-x\\nx-x-x-x-\\n-x-x-x-x\\npppppppp\\nrnbkqbnr\"\n",
    "new_string =      \"RNBQKBNR\\nPPPPPPPP\\n-x-x-x-x\\nx-x-x-x-\\n-x-x-n-x\\npppppppp\\nrnbkqb-r\"\n",
    "print(new_string)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Now, to be clear, it is certainly possible to make the “make_move” function work, but it does seem to have several small moving parts and therefore probably lots of interesting ways to go wrong. And then lets think about the more complex functions; if movement seems a bit tricky, how easy do we think defining checkmate is going to be?\n",
    "\n",
    "Basically, using strings seems doable but complicated. And as Tim Peters says, simple and complex are both better than complicated. Alright, on that note, let’s see if lists seem more straight-forward.\n",
    "\n",
    "#### The Board as a List\n",
    "\n",
    "       [[00, 01, 02],\n",
    "        [10, 11, 12],\n",
    "        [20, 21, 22]]\n",
    "        \n",
    "The above is a nested list but we have put each of the sublists on a new line to make it easier to visualise how such a structure can work like a game board. The numbers represent the (x, y) coordinate of that 'square'. And remember that lists can contain strings as well, so this option doesn't stop us from using those pretty graphics either.  \n",
    "\n",
    "Compared to the string implementation, the 1.Nf3 move should be somewhat straight-foward:\n",
    "    \n",
    "    Current_square  = {Black or White}\n",
    "    New_square      = {Knight}\n",
    "\n",
    "Current and New_squares being represented as something like 'board[x][y]'. At first glance, this seems considerably easier than a messing arround mutating strings. \n",
    "\n",
    "There is also another possible advantage to lists as well, and that is they can store a variety of data-types. I haven't spoken about classes in this lecture series and I'm not going to into detail * (classes are not suitable for a beginner class, in my opinion)* But, I’ll will very briefly introduce you to the concept and how we could use it here. \n",
    "\n",
    "Basically  Python makes it possible to create your own objects with their own methods. Yes, that’s right, we could *literally* make a “Knight” and give it the method ‘move to’. And yes, we could call the method just like any list or string method we have seen. \n",
    "\n",
    "Using classes then, it is, in some sense, *literally* possible to put a knight on a square on the board. Below I’ve provided a very rough sketch of what such a class could look like. Don’t bother running it though, it wont work because I’ve left out all the necessary bits of ‘low-level’ code."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 5,
   "metadata": {},
   "outputs": [
    {
     "ename": "NameError",
     "evalue": "name 'square' is not defined",
     "output_type": "error",
     "traceback": [
      "\u001b[0;31m---------------------------------------------------------------------------\u001b[0m",
      "\u001b[0;31mNameError\u001b[0m                                 Traceback (most recent call last)",
      "\u001b[0;32m<ipython-input-5-47c857f66a54>\u001b[0m in \u001b[0;36m<module>\u001b[0;34m()\u001b[0m\n\u001b[1;32m     20\u001b[0m \u001b[0;34m\u001b[0m\u001b[0m\n\u001b[1;32m     21\u001b[0m \u001b[0;31m# And once you have made the knight class we can make a knight.\u001b[0m\u001b[0;34m\u001b[0m\u001b[0;34m\u001b[0m\u001b[0m\n\u001b[0;32m---> 22\u001b[0;31m \u001b[0ma_knight\u001b[0m \u001b[0;34m=\u001b[0m \u001b[0mKnight\u001b[0m\u001b[0;34m(\u001b[0m\u001b[0msquare\u001b[0m\u001b[0;34m,\u001b[0m \u001b[0;34m\"White\"\u001b[0m\u001b[0;34m)\u001b[0m\u001b[0;34m\u001b[0m\u001b[0m\n\u001b[0m\u001b[1;32m     23\u001b[0m \u001b[0;34m\u001b[0m\u001b[0m\n\u001b[1;32m     24\u001b[0m \u001b[0;31m# Once the knight is made, we can move it using the move_to method:\u001b[0m\u001b[0;34m\u001b[0m\u001b[0;34m\u001b[0m\u001b[0m\n",
      "\u001b[0;31mNameError\u001b[0m: name 'square' is not defined"
     ]
    }
   ],
   "source": [
    "class Knight (object):\n",
    "    \n",
    "    def __init__ (self, current_square, colour):\n",
    "        \n",
    "        # define what this knight 'is', its properties etc\n",
    "        pass\n",
    "    \n",
    "    def legal_moves(square1, square2):\n",
    "        \"\"\"Checks if moving from square1 to square2 is a legal move for the peice.\n",
    "        Returns True/False\"\"\"\n",
    "        # Code goes here...\n",
    "        pass\n",
    "    \n",
    "    def move_to(self, square):\n",
    "        if legal_moves(current_square):\n",
    "            # Move to a square.\n",
    "            pass\n",
    "    \n",
    "    # Other methods goe here. \n",
    "\n",
    "# And once you have made the knight class we can make a knight. \n",
    "a_knight = Knight(square, \"White\")\n",
    "\n",
    "# Once the knight is made, we can move it using the move_to method:\n",
    "a_knight.move_to(new_square)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Defining Piece movement\n",
    "\n",
    "Alright, onto the next problem. \"How are we going to make the peices move?\" And once again a smart choice here will make things so much easier than it otherwise could be.\n",
    "\n",
    "One simple approach is to write a function for each piece, like so:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def bishop(position, board=\"\"):\n",
    "    \"\"\" When given a starting square, returns all squares the bishop can move to\"\"\"\n",
    "    pass\n",
    "    \n",
    "def rook(position, board=\"\"):\n",
    "    \"\"\" When given a starting square, returns all squares the rook can move to\"\"\"\n",
    "    pass\n",
    "    \n",
    "def queen(position, board=\"\"):\n",
    "    \"\"\"When given a starting square, returns all squares the queen can move to\"\"\"\n",
    "    pass"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "At first glance this code seems pretty good, but there are a few drawbacks. Firstly it looks like we are going to be repeating ourselves a lot; queen movement for example is just a copy & paste of the rook + bishop. The king function is likely a copy & paste of queen but where we change the distance to 1 and add a bunch of extra rules for check, and so on. \n",
    "\n",
    "And by the way guys, repeating oneself is NOT quite the same as reusing code! \n",
    "\n",
    "The second issue is that if we define movement in terms of an 8x8 board we lack generalisation of the problem.  How can we do better? Well, how about we define movement patterns and then define the pieces in terms of movement. Here, let me show you:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def diagonal(position, direction=\"frontleft, rearright, etc\", distance =1):\n",
    "    \"\"\"Returns all possible square in diagonal direction of n distance from original position\"\"\"\n",
    "    # code here\n",
    "    pass\n",
    "\n",
    "def row_movement(position, direction=\"left/right\", distance=1):\n",
    "    \"\"\"\n",
    "    >>> row_movement( (2, 2), direction=Left, distance =2)\n",
    "    [(2,2), (1, 2), (0, 2)]\n",
    "    >>> row_movement( (2, 2), direction=right, distance= 4)\n",
    "    [(2, 2), (3,2), (4,2), (5,2), (6,2)]\n",
    "    \"\"\"\n",
    "    \n",
    "    possible_moves = []\n",
    "    \n",
    "    if direction == left:\n",
    "        for move in range(distance):\n",
    "            possible_moves.append ( (x - move) )\n",
    "\n",
    "def col_movement(position, direction=\"up/down\", distance=1):\n",
    "    # code here\n",
    "    pass\n",
    "\n",
    "# ...and so on..."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Notice here that we have defined movement without reference to a board, our code here simply takes an (x,y) coordinate in space and will keep returning valid squares until it reaches the limit set by distance. The documentation in row movement explains the idea.\n",
    "\n",
    "With this generalisation, we should be able to handle larger or even rectangular boards. And now we can define pieces with just a few lines of code AND without repeating ourselves. Like so:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def queen_movement(position):\n",
    "    possible_moves = [diagonal(position, direction=\"all\", distance=\"infinite\"),\n",
    "                      row_movement(position, direction=\"all\", distance=\"infinite\")\n",
    "                      col_movement(postion, direction=\"all\", distance=\"infinite\")]\n",
    "    # ...and so on... \n",
    "    \n",
    "def pawn_movement(position):\n",
    "    \n",
    "    possible_moves = []\n",
    "    \n",
    "    if position == starting_position: # pawns move 2 from thier starting square.\n",
    "        col_movement(position, direction=\"up\", distance = 2)\n",
    "    else:\n",
    "        col_movement(position, direction=\"up\", distance = 1)\n",
    "    \n",
    "    if enemy_in_attack_range # Pawns attack diagonally but move forward/back.\n",
    "        diagonal(position, direction=\"forwardleft/right\", distance= 1)\n",
    "        \n",
    "    possible_moves = [col_movement, diagonal]\n",
    "    \n",
    "    # .. and so on... "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "So why might something like this be a good design choice? Well, to see the power of the this representation I think we we have to ‘zoom out’ a bit.\n",
    "\n",
    "Because pieces are defined in terms of general movement patterns we could easily invent new pieces with this code. And, as noted above, since we do not reference a board, we have given ourselves the ability to play chess on different size and shape boards. \n",
    "\n",
    "This means that if in a years time we want to write a checkers, shogi, or a capablanca chess program then we have already written a bunch of useful code for that project. Neat huh? \n",
    "\n",
    "To see another advantage lets think about some of the other rules in chess, castling, for example. Does this 'movement first' representation make the implementation of these functions easier? Perhaps..."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def kingside_castling(piece_1, peice_2):\n",
    "    \"\"\"where \"peice\" is a tuple/class containing (position, type, colour, other relevant facts...)\"\"\"\n",
    "    \n",
    "    # check pieces are king, rook, of same colour, in the right position\n",
    "    # check king is allowed to castle (e.g hasn't moved this game)\n",
    "    \n",
    "    # \"move_peice\" being some function defined elsewhere that moves a peice\n",
    "    move_peice(row_movement(king, direction=\"left\", distance=2))\n",
    "    move_peice(row_movement(Rook, dierection=\"right\", distance=2))\n",
    "    \n",
    "    # ... and so on ...       "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The thing to note here is that although we would have to code up specific checks to see if castling is legal, the actual castling itself is fairly easily handled by the 'row function' outlined above. Had we have gone with the individual piece representation we would have probably of been forced to write special if clauses within the King/Rook functions respectively.  \n",
    "\n",
    "But with this implementation, the special movement rule of castling is handled separately from normal movement. This should make our code easier to debug at a later date. \n",
    "\n",
    "Again, lets continue to dive deeper. How might check, checkmate, and statemate be defined given this implementation..."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def possible_moves(piece, position, friendly_position_list):\n",
    "    \"\"\" Returns all possible movement squares for given piece type at given position\"\"\"\n",
    "    if peice == pawn:\n",
    "        possible_moves = pawn_movement(position) # 'substract' all the squares other friendly units occupty/block\n",
    "    elif peice == queen:\n",
    "        pass\n",
    "    # ... and so on ...   \n",
    "    return (piece, moves)\n",
    "    \n",
    "def is_check(king_position, enemies = [enemy_piece, position] )\n",
    "    \n",
    "    # enemies would be a list of all remaining enemy peices; we store the peice type and its position\n",
    "    # eg, [ (Queen, b5), (Rook, a5), (pawn, d4), (pawn, e6), ... ] \n",
    "\n",
    "    for (enemy_piece, position) in enemies:\n",
    "        if king_position in possible_moves(enemy_peice, position):\n",
    "            return True \n",
    "    return False        "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Now that we have a ‘check’ function it seems like both mate and stalemate shouldn't be too hard to implement. In the case of stalemate, all we have to do is check if:\n",
    "\n",
    "* all possible king moves result in check (but the king is not currently in check)\n",
    "* no other move exists. (e.g our a3 pawn, cannot move, for example)\n",
    "\n",
    "What might that look like in code?"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "def is_stalemate(king position, enemies):\n",
    "    \n",
    "    # King in check? If yes, break\n",
    "    if not is_check(king_postion, enemies):\n",
    "        # Get all friendly moves...\n",
    "        for (move, piece) in possible_moves(All_friendlies, position):\n",
    "            # Check if all friendly moves result in check...\n",
    "            if not is_check(king, (move, piece) ):\n",
    "                return False\n",
    "        return True\n",
    "    return False"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Conclusion\n",
    "\n",
    "So today we moved away from the nitty-gritty and focused on the ‘big picture’. We looked at a few ways to represent a chess program in Python and although my code today was very ‘loose’ hopefully you guys the followed along and understood the main lesson I was trying to teach; **good, thought-out design matters; it makes coding faster, less frustrating, and also more expressive.**\n",
    "\n",
    "As we move toward the final project you would do well to remember some of these principles. Alright that’s it for this lecture, no homework this week. See ya next time!"
   ]
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.5.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}