Beginner question - How to effectively pass a large list

[Bengt Richter]

On Wed, 17 Dec 2003 18:46:10 GMT, alan.gauld at btinternet.com (Alan Gauld) wrote:

>On Tue, 16 Dec 2003 16:21:00 +0800, "J.R." <j.r.gao at motorola.com>
>wrote:
>> Actually, the python is passing the identity (i.e. memory address) of each
>> parameter, and it will bind to a local name within the function.
>> 
>> Right?
Depends on what you mean by "python" ;-) Python the language doesn't pass memory
addresses, but an implementation of Python might very well. The distinction is
important, or implementation features will be misconstrued as language features.

I suspect Alan is trying to steer you away from discussing implementation. I think
it can be useful to talk about both, if the discussion can be plain about which
it is talking about.
>
>Nope.
IMO that is a little too dismissive ;-)

>This is one case where understanding something of the insides of
>Python helps. Basically Python variables are dictionary entries.
>The variable values are the the dictionary values associated with
>the variable names which are the dictionary keys.
>
>Thus when you pass an argument to a function you are passing a
>dictionary key. When the function uses the argument it looks up
>the dictionary and uses the value found there.
That's either plain wrong or mighty misleading. IOW this glosses
over (not to say mangles) some important details, and not just of
the implementation. E.g., when you write

    foo(bar)

you are not passing a "key" (bar) to foo. Yes, foo will get access to
the object indicated by bar by looking in _a_ "dictionary". But
when foo accesses bar, it will be using as "key" the parameter name specified
in the parameter list of the foo definition, which will be found in _another_
"dictionary", i.e., the one defining the local namespace of foo. I.e., if foo is

    def foo(x): return 2*x

and we call foo thus
    bar = 123
    print foo(bar)

What happens is that 'bar' is a key in the global (or enclosing) scope and 'x' is a
key in foo's local scope. Thus foo never sees 'bar', it sees 'x'. It is the job of
the function-calling implementation to bind parameter name x to the same thing as the specified
arg name (bar here) is bound to, before the first line in foo is executed. You could write

    globals()['bar'] = 123
    print foo(globals['bar'])

and

    def foo(x): return locals()['x']*2

to get the flavor of what's happening. Functions would be little more than global-access macros
if it were not for the dynamic of binding local function parameter names to the call-time args.
>
>This applies to all sorts of things in Python including modules -
>a local dictionary associated with the module, and classes -
>another dictionary. Dictionaries are fundamental to how Python
>works and memory addresses per se play no part in the procedings.
Well, ISTM that is contrasting implementation and semantics. IOW, memory addresses may
(and very likely do) or may not play a part in the implementation, but Python
the language is not concerned with that for its _definition_ (though of course implementers
and users are concerned about _implementation_ for performance reasons).

I think the concept of name space is more abstract and more helpful in encompassing the
various ways of finding objects by name that python implements. E.g., when you interactively
type dir(some_object), you will get a list of key names, but typically not from one single dictionary.
There is potentially a complex graph of "dictionaries" to search according to specific rules
defining order for the name in question. Thus one could speak of the whole collection of visible
names in that process as a (complex) name space, or one could speak of a particular dict as
implementing a (simple) name space.

HTH

Regards,
Bengt Richter