Yup. That's all you. I barely understand how it works
It's not too difficult. It's just an extension of the anonymous parameters/arguments already used with functions/methods ; named
args (as in "
argument
s") and
kwargs (as in "
key
word
argument
s") by convention.
When you declare a function, you've to give the arguments it expect, and their names. By example,
def myFunction( text, enabled=True ):.
Then something like
myFunction( "choice 1", enabled=False ) will assign
choice 1 to the variable named
text, and the value
False to the variable named
enabled.
Your function could looks like that:
Code:
def myFunction( text, enabled=False ):
if enabled is True:
renpy.notify( text )
One day, you decide to add a "hint" parameter/argument, and for this you'll change the declaration of your function into
def myFunction( text, enabled=True, hint="No hint" ): ; if you don't do it, Ren'py/Python will complain that there's too many arguments.
But you can also decide to declare your arguments anonymously with
def myAnonFunction( *args, **kwargs ):. All the "regular arguments" will be stored into a list named
args, in their order or appearance, while all the "keyword arguments" will be stored into a dict named
kwargs. You call the function in the exact same way, but now the code of your function would looks like that:
Code:
def myAnonFunction( *args, **kwargs ):
if "enabled" in kwargs and kwargs["enabled"] is True:
renpy.notify( args[0] )
Then, when you'll add the "hint" optional parameter/argument you'll have to... well, you'll just have to change the code of your function, but not its declaration.
Anonymous parameters/arguments are generally used when you don't control the parameters/arguments ; by example when you overwrite an inherited method. Or when there's really too many parameters/arguments and they are too versatile. It's by example the case for the
Character object, where you can redefine part of the "say" style when you create the object. It would be a pain in the ass to declare a parameter/argument for "who_color", "who_size", "what_color", "what_size", and all the other possibilities. Instead, the class
__int__ method is declared with :
def __init__( self, name=NotSet, kind=None, **properties): ; note that, as I said,
args and
kwargs are just convention, you can use more explicit names, like it's the case here.
[More about args/kwargs can be found
here.]
What lead me to the menu choice. Most of the time, you'll use them without parameters/arguments, and must be said that having to declare the ones you'll possibly use would be a difficult task. Therefore, PyTom opted for the anonymous approach, exactly like if each choice was a function. What mean that
menu syntax should be seen as (with bracket marking the "optionality":
Code:
menu [label][(named_parameters)]:
choice [(*args, **kwargs)][condition]:
statements
And, each menu item (the
i in your example) is used to carry the
args list and
kwargs dict. This exactly like it already carry the text of the choice in
text, and what have to be done if the choice is selected in
action.
Are you saying "avoid this" or "this would be better"?
Avoid this.
Around half of devs shorten Boolean tests by simply removing the
is True/
is False part. It's bad, but not totally wrong.
But it have side effect, since it don't to discriminate between
False and
None:
Code:
label whatever:
$ myVar = False
if not myVar:
"myVar value is False"
$ myVar = None
if not myVar:
"myVar value is... er, False ?"
It's always better to have a default value that is really at the opposite of the value that is significant to you ; as least each time it's possible.
Edit:
A typo in the syntax.
