First attempt at a Python prog (Chess)

[Rick Johnson]

On Thursday, February 14, 2013 11:48:10 AM UTC-6, Chris Hinsley wrote:

> Is a Python list as fast as a bytearray?

Why would you care about that now? Are you running this code on the Xerox Alto? Excuse me for the sarcasm but your post title has perplexed me:

 "First attempt at a Python prog (Chess)" 
 
Okay, but how does that translate to: 

"The fastest, most efficient, most brain fricked python code ever released in the form of a game, that just happens to look an awful lot like C source"? 

    http://en.wikipedia.org/wiki/Optimization_%28computer_science%29#When_to_optimize

Why bother to use Python if what you really want to write is C code? If you want to write good code (not just python), you need to write code that is maintainable. Yes i KNOW, this is just some stupid chess game, but i can assure you that this style of code is only going to harm your evolution. This code is obfuscated at best and BF'ed at worst. And forget about the algorithms for now, the first problems to address are superficial.

First of all your naming conventions suck. You've used the "interface" style for every function in this game so i can't /easily/ eyeball parse the /real/ interface functions from the helper functions -- and i'm not going to even try, because i don't read ugly code! Try to learn the Python style guide as soon as you can (In particular pay attention to naming conventions):

 http://www.python.org/dev/peps/pep-0008/

Secondly this game could benefit from some OOP paradigm (not sure if are familiar with OOP or not???). But don't go bat-crazy with OOP! You don't need an object to represent /every/ single piece on the board (That would be nuts!). You need just enough OOP to encapsulate the data and create a proper interface. 

A good litmus test is based on the "three little bears":

 "Papa bears bed is too hard"

A hard utilization of paradigms wields too little OOP and therefore ends up being too difficult (aka: "hard") to maintain because there is no logical interface; just a massive collection of functions stuffed into global space until BF reaches critical mass and you're forced to do a complete re-write! (Of course sometimes you don't need OOP at all, just interface)
 
 "Mama bears bed is too soft"

A soft utilization of paradigms wields too much OOP whereby you are surrounded by big FAT objects which are smothering you to death, and they smell because they cannot properly wash themselves between the rolls of fat.

 "but baby bears is just right" 

Ahhh, the blissful comfort of a paradigm utilization that is "just right". This is where your code should be, you want a level of OOP usage that is "just right" for the occasion; not any more, not any less. 

## START EXAMPLE CODE ##
class GameBoard(???):
    def __init__(self):
        self.board = self._createBoard()
        
    def __str__(self):
        """Override:"""
        # return a string represention of the board
        # suitable for writing to stdout
        
    def _createBoard(self):
        """Internal:"""
        self.board = [blah]
       
    def make_move(self, piece, vector):
        """Interface: move a game piece based on vector"""
        # Find and move the piece. Whether the pieces
        # are objects or not doesn't matter.
        
class GamePiece(object):
    def __init__(self, typename, color):
        self.typeName = typeName
        self.color = color
        self.captureFlag = self._computeFlag()


def main():
    board = Board()
    playing = True
    while playing is not False
        i = input('PieceName - MoveVec:')
        n, v = parse(i)
        result = board.make_move(n, v)
        if result == 'GameOver':
            playing = False
        else:
            # clear the stdout
            str(board)
        

if __name__ == '__main__:
    main()
## END EXAMPLE CODE ##

And now you have the added benefit of exporting the objects for use elsewhere.