By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,100 Members | 2,979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,100 IT Pros & Developers. It's quick & easy.

accessing class attributes

P: n/a
Hello,

I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:
http://aspn.activestate.com/ASPN/Coo.../Recipe/413486

So, I've defined:

class Game:
self.GameState = Enum('running', 'paused', 'gameover')

def __init__
... etc

Later, each time I want to assign a variable some state, or check for
the state, I must do:

if state == self.GameState.running:

This is somewhat long and tiresome to type, outweighing the benefits
of this method over simple strings.

Is there any better way, to allow for faster access to this type, or
do I always have to go all the way ? What do other Python programmers
usually use for such "enumeration-obvious" types like state ?

Thanks in advance
Eli
Jun 27 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
eliben wrote:
Hello,

I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:
http://aspn.activestate.com/ASPN/Coo.../Recipe/413486

So, I've defined:

class Game:
self.GameState = Enum('running', 'paused', 'gameover')
That can't be what you've got. But I think I can guess what you meant
to show here.)
def __init__
... etc
Several options:

Define the Enum outside the class:
GameState = Enum('running', 'paused', 'gameover')
then later
class Game:
...
if state == GameState.running:
...
Or just simply define some values
RUNNING = 0
PAUSED = 1
GAMEOVER = 2
then later:
class Game:
...
if state == RUNNING:
...
Or try this shortcut (for the exact same effect):
RUNNING, PAUSED, GAMEOVER = range(3)

Gary Herron

Later, each time I want to assign a variable some state, or check for
the state, I must do:

if state == self.GameState.running:

This is somewhat long and tiresome to type, outweighing the benefits
of this method over simple strings.

Is there any better way, to allow for faster access to this type, or
do I always have to go all the way ? What do other Python programmers
usually use for such "enumeration-obvious" types like state ?

Thanks in advance
Eli
--
http://mail.python.org/mailman/listinfo/python-list
Jun 27 '08 #2

P: n/a
eliben <el****@gmail.comwrites:
Hello,

I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:
http://aspn.activestate.com/ASPN/Coo.../Recipe/413486

So, I've defined:

class Game:
self.GameState = Enum('running', 'paused', 'gameover')

def __init__
... etc

Later, each time I want to assign a variable some state, or check for
the state, I must do:

if state == self.GameState.running:

This is somewhat long and tiresome to type, outweighing the benefits
of this method over simple strings.

Is there any better way, to allow for faster access to this type, or
do I always have to go all the way ? What do other Python programmers
usually use for such "enumeration-obvious" types like state ?
Why not define GameState outside your Game class?

Then you can write:

if state == GameState.running

which is slightly shorter.

Or you could do:

class Game:
RUNNING, PAUSED, GAMEOVER = 0, 1, 2

and test like this:

if state == Game.RUNNING

Or, I've just thought of this simple state class:

class State(object):
def __init__(self, state):
object.__setattr__(self, '_state', state)
def __getattr__(self, attr):
return attr == self._state
def __setattr__(self, attr, val):
object.__setattr__(self, '_state', attr)
>>state = State('running')
state.running
True
>>state.paused
False
>>state.paused = True
state.paused
True
>>state.running
False

So you could write:

if state.running: ...

--
Arnaud

Jun 27 '08 #3

P: n/a
On May 28, 12:09 pm, eliben <eli...@gmail.comwrote:
Hello,

I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:http://aspn.activestate.com/ASPN/Coo.../Recipe/413486
[...]
Is there any better way, to allow for faster access to this type, or
do I always have to go all the way ? What do other Python programmers
usually use for such "enumeration-obvious" types like state ?
I tend to use string constants defined at the module level, e.g.:

##----- in jobclass.py:
# Status indicators
IDLE = 'IDLE'
RUNNING = 'RUNNING'
FINISHED = 'FINISHED'

class Job(Thread):
def __init__(self):
Thread.__init__(self)
self.status = IDLE

def run(self):
self.status = RUNNING
self.do_work()
self.status = FINISHED
[...]
##----- in another module
job = jobclass.Job()
job.start()
while job.status == jobclass.RUNNING:
print 'Job is running.'
time.sleep(SLEEP_SECONDS)
##-----

I've also used dummy objects, eg:

##-----
class RunStatus:
pass
IDLE = RunStatus()
RUNNING = RunStatus()
FINISHED = RunStatus()
##-----

I've had lots of success with these two methods. If you think an
enumeration is the most appropriate way, then:

##-----
RunStatuses = Enum('idle', 'running', 'finished')
IDLE = RunStatuses.idle
RUNNING = RunStatuses.running
FINISHED = RunStatuses.finished
##-----

I figure if you're only going to have a few dozen enumeration values,
then don't worry about cluttering up the module namespace with
variable names for constants.

Geoff G-T
Jun 27 '08 #4

P: n/a
I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:http://aspn.activestate.com/ASPN/Coo.../Recipe/413486

I frequently use strings in place of enumeration in python. I have
found it to be very useful. I'm curious about the _many negatives_ you
have found?

For example, I wrote a module and one of the parameters to a function
was `mode`. Two of the modes were ALL_MODE and ONE_MODE.

At first I enumerated the modes:

MODES = ALL_MODE, ONE_MODE = 0, 1

And code using the mode tended to look something like this:

from package import module
module.foo(mode=module.ALL_MODE)

Of course, the following would also work, but isn't self descriptive:

module.foo(mode=0)

Then, after some user feedback I changed it to this:

MODES = ALL_MODE, ONE_MODE = "all one".split()

This maintained backwards compatabilty, but users could use the much
more concise (but still readable) version:

module.foo(mode="all")

Since then, I have adopted using strings in place of enum types as a
best practice.

Matt
Jun 27 '08 #5

P: n/a
On May 29, 3:08 am, Matimus <mccre...@gmail.comwrote:
I have a game class, and the game has a state. Seeing that Python has
no enumeration type, at first I used strings to represent states:
"paused", "running", etc. But such a representation has many
negatives, so I decided to look at the Enum implementation given here:http://aspn.activestate.com/ASPN/Coo.../Recipe/413486

I frequently use strings in place of enumeration in python. I have
found it to be very useful. I'm curious about the _many negatives_ you
have found?

For example, I wrote a module and one of the parameters to a function
was `mode`. Two of the modes were ALL_MODE and ONE_MODE.

At first I enumerated the modes:

MODES = ALL_MODE, ONE_MODE = 0, 1

And code using the mode tended to look something like this:

from package import module
module.foo(mode=module.ALL_MODE)

Of course, the following would also work, but isn't self descriptive:

module.foo(mode=0)

Then, after some user feedback I changed it to this:

MODES = ALL_MODE, ONE_MODE = "all one".split()

This maintained backwards compatabilty, but users could use the much
more concise (but still readable) version:

module.foo(mode="all")

Since then, I have adopted using strings in place of enum types as a
best practice.

Matt
The problem with naming strings explicitly has to do with type safety.
If you make a mistake in a parameter's name, it won't be detected by
the interpreter and you can run into weird errors later. The other
problem is that all the possible options are not documented in one
convenient place, but you solved it by using a mixed approach of
uppercase "constants" having the values of strings.

Eli
Jun 27 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.