Chris Angelico <ros...@gmail.com> writes:
> On Fri, Nov 20, 2015 at 5:42 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>> BartC on the other hand is just complaining about an aspect of Python
>> that is legitimately controversial.
>
> IMO it's controversial mainly because there's an easy and obvious
> syntax for early binding, but late binding doesn't have syntactic
> support, and all the options are imperfect.
I do not think that we should get additional syntax for lately bound
default values. It would explicitely introduce the concepts
early versus late binding which are likely difficult to understand
by many users.
In addition, the last few days have had two discussions in this list
demonstrating the conceptial difficulties of late binding -- one of them:
Why does "[lambda x: i * x for i in range(4)]" gives
a list of essentially the same functions?
Note as well, that it is difficult to define what "late binding"
should mean in non-trivial cases:
def f(..., a=<some complex expression, involving variable references>)
If "a" is lately bound, when are bound the variables involved
in its defining expression?
If they are early bound, you get the same effect as with realy
bound default parameters: calling the function can change non local
objects which may lead to surprises.
If they are lately bound, the references may no longer be
resolvable or (worse) may resolve to unexpected objects.
If you need late binding, you might use something like this:
class Late(object):
def __init__(self, obj): self.obj = obj
def bind:
from copy import deepcopy
return deepcopy(obj)
def __repr__: ...
def f(..., a=Late(<expr>)):
...
a = a.bind()
...
Of course, you could define a decorator which performs the
"bind" calls automatically.
--
https://mail.python.org/mailman/listinfo/python-list
