On 2013-02-15 05:05:27 +0000, Rick Johnson said:
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.
Wow, such vitriol for such a simple bear to cope with !
Maybe Papa bear would like to try some humility !
This was my very first Python prog, and my first chess prog and my
attempt to learn somthing about Generators ! Do youtself a favour and
leave the Python comunity for the good of the language !
Chris
--
https://mail.python.org/mailman/listinfo/python-list
