I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Tue, 7 Jun 2016 02:57 am, Random832 wrote:

> On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote:
>> (2) The "variables are like boxes" metaphor applies to static languages
>> like
>> C and Pascal, where the compiler has knowledge of what variables will
>> exist. Such languages allocate space for the variables at compile time,
>> usually using fixed memory locations on the stack, or in registers, but
>> rarely dynamically in the heap.
> 
> As you're so fond of pointing out, those are implementation details. 

I believe that both C and Pascal specify that they are statically declared
languages with a variable model broadly as I have described it above,
the "box" model.

There may be implementation-dependent details I've glossed over (I don't
know the entire Pascal and C specifications by heart), but I think I'm on
fairly solid ground to say that a language that is just like C except that
it allocates variables in a hash table at runtime, using runtime lookups
for variable access, would not satisfy the C89 or C99 standards.

In any case, the point is that there are behavioural differences between a
static "box" model and a dynamic "name binding" mode for variables. Python
uses the later, not the former. You couldn't implement Python with a
strictly static box model, since you have to support `exec`.


> And 
> CPython does it too (using frame objects rather than the stack, but the
> relevant point here is that it *does* have knowledge of what variables
> will exist), for local variables.

A very good point, however that *is* an implementation detail: Jython and
IronPython don't have that limitation, as CPython does, and so their
locals() is a proper namespace. But even in CPython 2, you can create local
variables dynamically:


py> def test():
...     exec("x = 1")
...     print(x)
...
py> test()
1


Though that doesn't work in Python 3.


>> That's exactly what Python doesn't do.
> 
> And anyway, the fact that the "boxes" are dynamically allocated rather
> than "fixed memory locations on the stack"* doesn't stop them from being
> boxes 

"Variables as boxes" is a long-standing, well-known metaphor for the C and
Pascal variable model, one where the value is copied into the box
(metaphorically), or to be more precise, where variables have fixed
locations and on assignment values are copied to that location. Python is
not like that, and using the same metaphor for two completely different
models is a sure way to get obfuscation and confusion rather than
understanding.

Weren't you the one who just a few days ago complained about Python folks
unilaterally redefining established terms in contradiction of how those
terms are used by the rest of the programming community?

The broader programming community understands "variables as boxes" to mean
fixed size boxes in fixed locations with assignment-as-copying, as used by
C and Pascal. I don't think it is helpful for you to invent your own
metaphor of Python-style variables being boxes.


> (if you prefer Marko's analogy, "Some puppies hold leashes in 
> their mouths").

I don't know what Marko's analogy is. Puppies with leashes? What?


> Attributes and list items and dictionary keys and values 
> are also boxes.

They're not boxes in the sense of the "variables are boxes" model. I don't
know what other sense you intend the metaphor to be understood.


> *isn't the whole point of it being a stack that they're not fixed? I
> assume you meant fixed offsets from the stack frame.

Yes, thank you for the correction. (That's not sarcasm.)




-- 
Steven