New methods in 2.49 ob.get(), ob.has_key()

Game Engine Game Engine Support and Discussion
1

Since some discussions a while back with Social these features were mentioned.
Added these just the other day (since rc3), so youll need a recent build to test.
Both functions match existing dictionary methods.

These 2 functions work for GameObjects and GameLists
ob = sce.objects.get(“OBfoo”) # OBfoo or None
ob = sce.objects.get(“OBfoo”, ob_default) # OBfoo or ob_default

if sce.objects.has_key(“OBfoo”): print “blah”

This also works just like hasattr for gameObjects

if hasattr(ob, “prop”): print ‘hello world’
-> if ob.has_key(“prop”): print ‘hello world’

prop = ob.get(“someProp”, 0) # always return the prop, 0 if it doesnt exist.

— Will mention in release logs but thought its worth posting here too.

2

That last one sounds like a way to detect if all objects with a property are gone, could be very useful for Lode Runner type games.

3

These are mostly useful to avoid exception handling.

try: ob = sce.objects[“OBfoo”]
except: ob = None

Can be replaced with…
ob = sce.objects.get(“OBfoo”)

if hasattr(ob, “prop”): val = ob.prop
else: val = 0

replace with…
val = ob.get(“prop”, 0)

4

ideasman!

either your description is wrong or there is a bug!
if ob.has_key(“prop”): print ‘hello world’ doesn’t work for me. I have to write
if ob.has_key(prop): print ‘hello world’

and the warning is misleading
and using hasattr gives a warning about val = ob.prop -> val = ob[“prop”], from your point of view it might be correct (it has to do with props…) but to me hasttr doesn’t look like val = ob.prop. When it says where it is it doesn’t use the word line, it just gives a number. A bit inconsistent from the other warnings.

For the first one you’ll have to decide if it is a bug or not, the second one will be filed as a bug soon if there is no reply.

5

@Sim88

  • ob.has_key(“prop”) vs ob.has_key(prop) - simply depends on your script, if prop is defined as a variable or if you have a property called prop.

  • hasattr is checking for attributes, since using a property as an attribute is being deprecated use of hasattr() should be removed. The misleading error is unfortunate but since python gets the attribute internally there is no way around this. - if you call a python function that gets the attribute it would cause the error too though give a more useful line number.

  • There is a bug in gameObject.get(“prop”) - which would not convert a float into a python float - for 2.49, was fixed a day or 2 after released :expressionless: As were the attribute warnings.

I could add in the warning that hasattr() should be relplaced by .has_key() for some of these confusing cases.

6

I just realised it was a mistake in my script, thought I had proof read it but I hadn’t done it good enough.

On a side note.
Checking docs.python.org for more dictionary methods I found: has_key() is deprecated in favor of key in d. http://docs.python.org/library/stdtypes.html#dict.has_key

7

Didn’t know about has_key being deprecated, bummer. though for our purpose has_key() is faster and more convenient for us.

The problem with making gameObject act like a sequence is that its not.
for prop in GameOb:… # can work
if prop in GameOb: … # too

if len(GameOb): # works but gives BIG problems…

if ob: # now checks len() and will fail on objects with no props.

So basically if you really want all the sequence operations on properties we need gameOb.properties and THAT can be used as a sequence, but not GameObject.

8

Update for 2.49a
Replaced (gameOb.has_key(“prop”)) with (“prop” in gameOb)
if “OBCube” in sce.objects: … works too

9

You said earlier that has_key is faster, is this still true? and will has_key stop to work at some point?

10

The “something in Dict” notation will be just as fast as .has_key() for the same reasons.

11

“prop” in gameOb will be a bit faster then gameOb.has_key(“prop”) since it doesnt have to allocate a python function and free it each time, though this is probably very minor compared to the speedup from hasattr to has_key().