Default method arguments

[Alex Martelli]

Gregory Petrosyan <gregory.petrosyan at gmail.com> wrote:
   ...
> def f(self, x = self.data)                           (*)
   ...
> So I think (*) is the best variant, but it doesn't work :(

It DOES work -- it just does not work the way you _expect_ it to work,
but rather, it works the way it's _defined_ to work.

Specifically: all the evaluation of default arguments' values happens as
a part of the execution of the 'def' statement, and so, in particular,
happens at the TIME 'def' is executing.

A 'def' statement which is at the top level in a 'class' statement
evaluates as part of the evaluation of 'class'.

So, if, *while the 'class' statement is evaluating*, something known as
'self' exists, and has a 'data' attribute, this will give you the
default value for argument 'x'.  If the name 'self' is unknown, or
refers to an object which has no 'data' attribute, then of course
appropriate exceptions get raised (NameError or AttributeError) when
Python is TRYING to execute that 'def' statement.

Here's an example in which this works without exceptions:

class outer(object):
    def __init__(self, data): self.data = data
    def make_inner(self):
        class inner(object):
            def f(self, x=self.data):
                print x
        return inner()

Now, y = outer(23).make_inner() gives you an instance of an inner class,
such that y.f() is the same thing as y.f(23).  The 'self.data' in the
'def f', since it's the evaluation of a default value for an argument,
evaluates at the time 'def' evaluates -- and, at that time, 'self'
refers to the instance of class outer that's the only argument to method
make_inner of class outer.

While such "factories" (classes and functions making and returning other
classes and functions) are rarely used by beginners, they are an
extremely important idiom for advanced users of Python.  But the point
is that, by having extremely simple and universal rules, it takes no
exoteric knowledge to understand what the above Python code will do --
default argument values evaluate as 'def' executes, therefore there is
absolutely no ambiguity or difficulty to understand when this
'self.data' in particular evaluates.

If Python tried to guess at when to evaluate default argument values,
sometimes during the 'def', sometimes abstrusely storing "something"
(technically a 'thunk') for potential future evaluation, understanding
what's going on in any given situation would become extremely
complicated.  There are many languages which attempt to ``helpfully''
"do what the programmer meant in each single case" rather than follow
simple, clear and universal rules about what happens when; as a
consequence, programmers in such "helpful" languages spend substantial
energy fighting their compilers to try and work around the compilers'
attempted "helpfulness".

Which is why I use Python instead.  Simplicity is a GREAT virtue!


If it's crucial to you to have some default argument value evaluated at
time X, then, by Python's simple rules, you know that you must arrange
for the 'def' statement itself to execute at time X.  In this case, for
example, if being able to have self.data as the default argument value
is the crucial aspect of the program, you must ensure that the 'def'
runs AFTER self.data has the value you desire.

For example:

class A(object):
    def __init__(self, n):
        self.data = n
        def f(self, x = self.data)
             print x
        self.f = f

This way, of course, each instance a of class A will have a SEPARATE
callable attribute a.f which is the function you desire; this is
inevitable, since functions store their default argument values as part
of their per-function data.  Since you want a.f and b.f to have
different default values for the argument (respectively a.data and
b.data), therefore a.f and b.f just cannot be the SAME function object
-- this is another way to look at your issue, in terms of what's stored
where rather than of what evaluates when, but of course it leads to
exactly the same conclusion.

In practice, the solutions based on None or sentinels that everybody has
been suggesting to you are undoubtedly preferable.  However, you can, if
you wish, get as fancy as you desire -- the next level of complication
beyond the simple factory above is to turn f into a custom descriptor
and play similar tricks in the __get__ method of f (after which, one can
start considering custom metaclasses).  Exactly because Python's rules
and building blocks are simple, clean, and sharp, you're empowered to
construct as much complication as you like on top of them.

That doesn't mean you SHOULD prefer complication to simplicity, but it
does mean that the decision is up to you.


Alex