[Tutor] Pass by reference

[D-Man]

On Fri, Jul 13, 2001 at 09:26:56AM +0530, Praveen Pathiyil wrote:
| I would like to thank Michael, Rob, D-Man, Wesley, Ibraheem, Remco and
| everybody else who helped me clarify my doubts ...

You're welcome.

| Also the differece this makes on the scope or life of that variable.

Scope and lifetime are often related, but are actually separate
issues.

Scope is determined entirely by the language definition.  In Python
new classes and new functions define new scope.  In C/C++/Java curly
braces define a new scope (basically every block of code starts a new
scope, but has access to outer scopes).

Variables on the stack live only as long as the function call.  Once
the function returns they are popped off the stack.  Heap variables
live as long as you want them to, up to program termination.  In
Python they are cleaned up for you by the ref counting or gc.  In
C/C++ you must explicitly free() or 'delete' them when you are done.


| I am continuing with my doubts :-))
| Can some one explain the differece between the allocation of variables or
| objects on the heap and that on the stack ? (May be from the python
| perspective itself).

All Python objects are on the heap.  This makes it simple :-).

In C, C++ or Java you have both a stack and a heap.  Take the
following C code, for example,

void func()
{
    int j ;  /* this is a stack variable */
    int* k ; /* this is a basically reference, the refernce is a stack
              * variable but it refers to data on the heap */

    /* this inizializes the memory allocated to j to have the value 2 */
    j = 2 ;

    /* this requests some memory (for a single integer) and lets k
     * refer to that chunk of memory */
    k = malloc( 1 * sizeof( int ) ) ;

    /* pointer dereferencing is explicit in C (that's what the '*'
     * does),
     * this initializes the memory refered to by k's value to have the
     * value 5 */
    *k = 5 ;
}

If I call this function,

function()

a new "stack frame" is added to the runtime stack.  This stack frame
holds all the state the runtime needs to deal with function calls  --
the address of the next instruction following the function call, all
local variables for the function, (other stuff?).  The variable 'j'
lives on the stack so it is "automatically" freed when the function
returns.  It can be used "normally" (in a python sense).  The variable
'k' is also on the stack, but it is a pointer (reference).  Its value
isn't usually directly useful (it is a memory address) but it can
point to memory on the heap (ie the call to 'malloc').  The 'malloc'
library marks the heap memory as in-use.  The pointer must be
explicitly dereferenced in C (this is automatic in Python) in order to
access the heap memory it refers to.  When the function returns, 'j'
and 'k' are both popped off the stack.  However, the heap memory that
k referred to is still flagged as in-use even though nothing refers to
it because I didn't free() it.  This is known as a memory leak.  That
heap memory will be allocated until the program terminates.

I'm sure that I've completely confused you now, but don't worry about
it -- you're using Python, not C.  The reason I jumped to C here is
because C (and C++) programmers must worry about stack allocated vs.
heap allocated objects in their program design and implementation.  In
Python all objects live on the heap and are "garbage collected" for
you.  Python does have a stack (that is how it knows where to return
to when a function returns) but the only thing in the stack are
_references_ to heap objects (local variables in functions).  There
are no _objects_ on the Python stack.

Basically you don't need to worry about it unless you want to go
deeper into computer and programming language operation and want to
learn a language like C or C++ where memory management is the
programmer's responsibility, rather than taken care of by the
interpreter.

| One un-related question --> Why was strings made as immutable in python ?

I don't know, but I bet Tim Peters does <wink>.  My guesses are as
follows :

    o  simpler to implement
    o  can be "interned" (cached?) because they can't be changed
    o  umm, probably because C strings aren't the most pleasant
        structures to deal with and python was implemented in C
        (BTW Java's java.lang.String are also immutable and this is
         the basis for strings in Jython)

HTH,
-D