how to show name of player that you are pointing to

[Mahi]

You simply have two methods, get & set, plus a property that makes accessing these easier (but does the same thing). I think the .setter stuff would make code less readable. Don't know about the alpha parameter tho.

What's so wrong about having two methods and then a wrapper for both of them as a property? You said it yourself, you can do things this or that way. SP lets scripters use which they want (set&get or property). I think the work done is very pythonic and quality work.

I can't see how they're less readable, especially when people shouldn't be looking at their implementation, but their usage:

Syntax: Select all

player.set_health(player.get_health() + 5)
# vs
player.health += 5

I find it much more readable :P

Now, having get&set and a property is the problem here, why have two ways to do this?
It's more complicated and confusing for new people when they might not know that those do the exact same thing, to be honest I would guess that player.health is not a property but an attribute if I saw player.set_health() being used (without seeing the implementation).
Also, there's absolutely no benefit of letting everyone use which way they want, it's just creating extra fuzz and C/P code will eventually look awful:

Syntax: Select all

@Event
def player_jump(game_event):
    player = PlayerEntity(index_from_userid(game_event.get_int('userid')))
    if player.health > 1:
        player.set_health(player.get_health() - 1)
    if player.speed < 2.0:
        player.set_speed(player.speed + 0.01)

And you'd have to convert all the player.set_health(x) commands into player.health = x if you were to use someone elses code inside of yours.

The code is

• readable
• easy to understand (informative docstrings)
• structured
• extensible via .ini files (easy way to create better support for more games)

Doesn't make any sense, all this is true and even more true if using only properties instead of get&set along with properties.

The property is defined in the respective .ini file, the Enity/PlayerEntity class basically looks for these entity properties (like kills) in the file and maps them to their respective values (like m_iFrags) using python properties, thus creating an easy way to read and change the value.

What's wrong with letting SP do the hard work and letting players use what Satoon mentioned here?

Syntax: Select all

player = PlayerEntity(1)

# Get the player's kills using attributes
kills = player.kills

# Set the player's kills using attributes
player.kills = 20

# Get the player's kills using get_property_<type>
kills = player.get_property_int('m_iFrags')

# Set the player's kills using set_property_<type>
player.set_property_int('m_iFrags', 20)

I'm sorry but I don't quite get what you're trying to say. I think we completely agree on properties being the correct solution here, so no need to argue about this part.
I never said there's anything wrong about that, I said:

What comes to your last example (setting the kills in "two different ways"), that's basically what properties are for.

So basically they're using it properly right here.

[L'In20Cible]

I didn't read the entire thread but I can agree that I prefer properties over accessor/mutator methods for accessibility of python magic. However, I believe both ways are fine here. The methods makes mapping, etc. easier.

[XE_ManUp]

I can tell you that in our job (I work in Python for a living), we have all agreed that the @x.getter and @x.setter methods add to code complexity, as it attracts the eye thinking it is a decorator with additional restrictions. To be honest, we typically use @property for read-only items.

You gave several examples which are valid using both methods. However, I find that the classic method is more readable. While there should be only one obvious way to do things, we also have to consider that explicit is better than implicit. To me, that wins over almost everything in Zen.

TLDR; - there's no wrong way to eat a Reese's.