Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #99130 > unrolled thread

Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) dieter <dieter@handshake.de> - 2015-11-20 08:49 +0100
    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Jussi Piitulainen <harvesting@is.invalid> - 2015-11-20 10:49 +0200
      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) dieter <dieter@handshake.de> - 2015-11-21 08:26 +0100

#99130 — Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Nov 20, 2015 at 5:42 AM, Ian Kelly <ian.g.kelly@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.
    

[toc] | [next] | [standalone]

#99134

dieter writes:
> Chris Angelico writes:
>
>> 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.

I'm confused by the term. I don't like it one bit.

"Early binding" of a default value seems to mean that the expression
that produces the default value of a function parameter is evaluated
when the function is defined. "Late binding" seems to mean that the
expression is evaluated when the function is called.

In both cases the actual binding of the parameter to the value (either
the default or an actual argument) is established when the function is
called. Several different bindings of that same parameter to different
values can hold simultaneously, so the *binding* has to be conceptually
"late". Because recursion.

Why isn't the evaluation of the default expression called evaluation?
Or at least something that doesn't already mean something else that is
as crucially important as, well, I've already given up on talking about
REDACTED and REDACTED in connection with Python, and here I see related
established terminology used for something else *for no reason that I
can see*.

I see no *need* to call this other thing "binding".

[toc] | [prev] | [next] | [standalone]

#99198

Jussi Piitulainen <harvesting@is.invalid> writes:
> dieter writes:
>> Chris Angelico writes:
>>
>>> 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.
>
> I'm confused by the term. I don't like it one bit.
>
> "Early binding" of a default value seems to mean that the expression
> that produces the default value of a function parameter is evaluated
> when the function is defined. "Late binding" seems to mean that the
> expression is evaluated when the function is called.
>
> In both cases the actual binding of the parameter to the value (either
> the default or an actual argument) is established when the function is
> called. Several different bindings of that same parameter to different
> values can hold simultaneously, so the *binding* has to be conceptually
> "late". Because recursion.

Conventionally, "binding" is the association of a "value" with a "name".

In this sense, you can call "early binding" the current Python behavior
with respect to default parameters: the expression is evaluated into
a "value" at function definition time and bound to the parameter name.
A later call may rebind the parameter name (if it provides its own value).

In the case of "late binding", the function definition would also
bind at function definition time the "name"
to something (but not a "value"): an expression,
maybe together with some binding. This expression would then
be evaluated at a later time (and we only then get the typical
binding of a "name" to a "value").


> Why isn't the evaluation of the default expression called evaluation?

I do not mind if you prefer to use the term "evaluation"
instead of "binding". Nothing important in my previous message
would be changed by the term exchange: you must specify how (and when)
the variables referenced in the expression get their values. And
this will give new difficulties - more serious than
Python's current handling of default parameters.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web