YAI: syntax for preset locals without using dummy args with defaults

[Bengt Richter]

On Fri, 10 Jan 2003 10:05:09 -0600, Skip Montanaro <skip at pobox.com> wrote:

>    Bengt> Right now we often see
>
>    Bengt>     def foo(x, y=default, z=some_expression):
>    Bengt>         ...
>
>    Bengt> where the purpose is not to have three parameters, but two plus a
>    Bengt> local binding (z) in foo to the value of some_expression
>    Bengt> evaluated in the def-time environment. 
>
>This is just a performance hack and should be addressed by other means,
You are commenting on my introductory background paragraph, and I am not
sure whether you ignored the rest ;-/

I agree that abusing default args is a hack, that's why I posted what followed,
which was a proposal of one way to have it "addressed by other means." ;-)

>e.g., more efficient access to global variables.  See, for example, PEPs 266
>and 267.  I believe other not-yet--PEPped proposals have been floated as
>well.
I just had a brief look at 266 and 267. IMO tracking changes to a binding
that was used in the past to find an object smacks of C variable thinking.

IOW, it would be a change in the *object* that should be of interest, not
a change in some name's binding in some module's dictionary. Why would
a change there be of interest, unless it's known to be a dynamically changing
binding, and you are specifically interested in tracking that? That certainly
wouldn't be the case for most elements of library modules etc.

I guess the point is that a bunch of code is written with multi-dotted attribute
chains even inside of hot loops, but that is just as bad as reevaluating constant
arithmetic expressions that could be hoisted out of a loop. Since there is
no optimizer that knows whether we mean what we write, we have to do that
by hand.

IMO, I just provided a simple syntax for writing what we mean without abusing
defaults, but providing a logical up-front place for local bindings to objects
that don't need to be lookup up more than once.

Of course that doesn't improve the performance of legacy code, and ;-)

It is pretty ugly to contemplate monitoring dictionary updates all over the
place to trigger re-evaluations of expressions that may be dependent on
particular name rebindings. What if the expression has a side effect? When do
you want it and when don't you? I think it will be hard to generalize without
some declarative hints or plain restricted definitions of "how it's going to be." ;-)

BTW, my newsreader doesn't pick up Cliff's post as part of this thread. Is that
just my problem, or what makes that happen? I've seen a few other examples.

Regards,
Bengt Richter