[Python-ideas] 'Injecting' objects as function-local constants

[Raymond Hettinger]

On Jun 18, 2011, at 10:22 PM, Carl M. Johnson wrote:

> On Sat, Jun 18, 2011 at 1:04 AM, Jacob Holm <jh at improva.dk> wrote:
> 
>> A consequence of this would be that you could optionally allow
>> "nonlocal" to bind global names when there are no suitable nonlocal
>> names to bind to (e.g. in a top-level function).  It has always slightly
>> bothered me that you couldn't do that, because it makes it harder to
>> move code between levels.
> 
> I will say that I was surprised to discover that `nonlocal` can be
> used only for outer function locals and not for globals, since the
> name "nonlocal" seems very general, as if it encompassed all things
> not local. If it could be changed, I think it would be a little more
> intuitive. In addition, as you mention, it's slightly better for
> refactoring.

We should put a stop the notion that any time someone says,
"I was surprised" that there needs to be a change to the language.
If surprise happens because someone skipped reading the docs
and made an incorrect guess about how a keyword  behaves
(i.e. using a new feature without reading about what it actually does),
then "I was surprised" means very little.

No matter what was implemented for "nonlocal", someone
was going to be surprised that it didn't match their intuition.
If nonlocal meant, "first match in the chain of enclosing scopes",
then would you expect "nonlocal int" to write into the builtin scope?
If nonlocal included globals, would it be a surprise that "global x"
and "nonlocal x" would do exactly the same thing, but only if x
already existed in the global scope?  Whatever the answers,
the important point is that it is hard to eliminate surprise when
surprise is based on someone's guess about how a keyword
is implemented.   One the Python Weekly URL's quotes of the
week last month was:  "When did we suddenly come to expect
that people could program in a language without actually learning it?"

ISTM, it would be much better if language change proposals came
in the form of:  "change X makes the following code better and is
worth the breaking of code Y and making person Z relearn what
the feature does."  That would get to essentials while taking the
unpersuasive "I was surprised" off the table.

my-two-cents-ly,


Raymond