Understanding python functions - Instant Python tutorial

Discussion in 'Python' started by Chris Carlen, Jul 13, 2007.

  1. Chris Carlen

    Chris Carlen Guest

    Hi:

    I have begun learning Python by experimenting with the code snippets here:

    http://hetland.org/writing/instant-python.html

    In the section on functions, Magnus Lie Hetland writes:

    --------------------------------------------------------------------
    For those of you who understand it: When you pass a parameter to a
    function, you bind the parameter to the value, thus creating a new
    reference. If you change the “contents” of this parameter name (i.e.
    rebind it) that won’t affect the original. This works just like in Java,
    for instance. Let’s take a look at an example:

    def change(some_list):
    some_list[1] = 4

    x = [1,2,3]
    change(x)
    print x # Prints out [1,4,3]

    As you can see, it is the original list that is passed in, and if the
    function changes it, these changes carry over to the place where the
    function was called. Note, however the behaviour in the following example:

    def nochange(x):
    x = 0

    y = 1
    nochange(y)
    print y # Prints out 1

    Why is there no change now? Because we don’t change the value! The value
    that is passed in is the number 1 — we can’t change a number in the same
    way that we change a list. The number 1 is (and will always be) the
    number 1. What we did do is change the contents of the local variable
    (parameter) x, and this does not carry over to the environment.
    --------------------------------------------------------------------

    What this looks like to me is what would happen if in C I passed a
    pointer to the list x to the function change(), as in:

    change(&x);

    Thus the function could change the original list.

    I don't understand Hetland's terminology though, when he is speaking of
    "binding" and "reference." Actually, Hetland's entire first paragraph
    is unclear.

    Can anyone reword this in a way that is understandable?


    Thanks.






    --
    Good day!

    ________________________________________
    Christopher R. Carlen
    Principal Laser&Electronics Technologist
    Sandia National Laboratories CA USA

    NOTE, delete texts: "RemoveThis" and
    "BOGUS" from email address to reply.
     
    Chris Carlen, Jul 13, 2007
    #1
    1. Advertising

  2. En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen
    <> escribió:

    > Hi:
    >
    > I have begun learning Python by experimenting with the code snippets
    > here:
    >
    > http://hetland.org/writing/instant-python.html
    >
    > In the section on functions, Magnus Lie Hetland writes:
    >
    > --------------------------------------------------------------------
    > For those of you who understand it: When you pass a parameter to a
    > function, you bind the parameter to the value, thus creating a new
    > reference. If you change the “contents†of this parameter name (i.e.
    > rebind it) that won’t affect the original. This works just like in Java,
    > for instance. Let’s take a look at an example:
    >
    > def change(some_list):
    > some_list[1] = 4
    >
    > x = [1,2,3]
    > change(x)
    > print x # Prints out [1,4,3]
    >
    > As you can see, it is the original list that is passed in, and if the
    > function changes it, these changes carry over to the place where the
    > function was called. Note, however the behaviour in the following
    > example:
    >
    > def nochange(x):
    > x = 0
    >
    > y = 1
    > nochange(y)
    > print y # Prints out 1
    >
    > Why is there no change now? Because we don’t change the value! The value
    > that is passed in is the number 1 — we can’t change a number in the same
    > way that we change a list. The number 1 is (and will always be) the
    > number 1. What we did do is change the contents of the local variable
    > (parameter) x, and this does not carry over to the environment.
    > --------------------------------------------------------------------
    >
    > What this looks like to me is what would happen if in C I passed a
    > pointer to the list x to the function change(), as in:
    >
    > change(&x);
    >
    > Thus the function could change the original list.
    >
    > I don't understand Hetland's terminology though, when he is speaking of
    > "binding" and "reference." Actually, Hetland's entire first paragraph
    > is unclear.
    >
    > Can anyone reword this in a way that is understandable?


    First, see this short article http://effbot.org/zone/python-objects.htm

    Now, forget about C "variables" and "pointers" because you won't get much
    far with those concepts.
    Objects exist - and we usually use names to refer to them. This line:

    a = 1

    means "make the name 'a' refer to the object 1", or, "bind the name 'a' to
    the instance of type int with value 1", or "let 'a' be a reference to the
    object 1"

    This line:

    some_list[1] = 4

    means "make the second element of some_list refer to the object 4", or
    "alter some_list so its element [1] is a reference to the object 4"

    bind the name 'a' to the instance of type int with value 1", or "let 'a'
    be a reference to the object 1"

    Note that some objects are immutable - like the number 1, which will
    always be the number 1 (*not* an integer "variable" that can hold any
    integer value). Other objects -like lists and dictionaries, by example, or
    most user defined classes- are mutable, and you can change its contents
    and properties. Modifying an object is not the same as rebinding its name:

    x = [1,2,3]
    y = x
    x[1] = 4
    print x # [1, 4, 3]
    print y # [1, 4, 3]

    x = [1,2,3]
    y = x
    x = [1,4,3]
    print x # [1, 4, 3]
    print y # [1, 2, 3]

    You can test is two names refer to the same object using the is operator:
    x is y. You will get True in the first case and False in the second case.

    --
    Gabriel Genellina
     
    Gabriel Genellina, Jul 13, 2007
    #2
    1. Advertising

  3. Chris Carlen

    Ben Finney Guest

    Chris Carlen <> writes:

    > I don't understand Hetland's terminology though, when he is speaking
    > of "binding" and "reference." Actually, Hetland's entire first
    > paragraph is unclear.
    >
    > Can anyone reword this in a way that is understandable?


    I've had some success with the following way of thinking about it.

    Some languages have "variables", which act like boxes that have names
    etched on the side. Once created, the box can contain an object, and
    it can be inspected while in the box; to change the variable, you
    throw out the object and put a different object in the same box.

    That's not how Python works. Every value is an object; the assignment
    operator binds a name to an object. This is more like writing the name
    on a sticky-note, and sticking it onto the object.

    * The object itself doesn't change or "move".

    * The object can be referred to by that name, but isn't "inside" the
    name in any way.

    * Assigning multiple names to the same object just means you can
    refer to that same object by all those names.

    * When a name goes away, the object still exists -- but it can't be
    referred to if there are no longer any names left on it.

    * Assigning a different object to an existing name just means that
    the same sticky-note has moved from the original object to the new
    one. Referring to the same name now references a different object,
    while the existing object keeps all the other names it had.

    When you pass an object as a parameter to a function, the object
    receives a new sticky-label: the parameter name under which it was
    received into the function scope. Assignment is an act of binding a
    name to an object; no new object is created, and it still has all the
    other names it had before.

    When the function ends, all the names that were created inside that
    function's scope disappear; but the objects still exist under any
    names they had previously, and if you use those names you'll be
    looking at the same object as was manipulated inside the function.

    When the object has lost all its names -- for example, they've
    disappeared because the scope they were in has closed, or they've been
    re-bound to other objects -- they can no longer be referenced. At some
    point after that, the automatic garbage collection will clean that
    object out of memory.


    This sticky-note analogy, and the behaviour described, is what is
    meant by "references". A name refers to an object; changing the object
    means that by referring to that same object under its different names,
    you will see the same, modified, object.

    In Python, all names are references to objects. The assignment
    operator '=' doesn't create or change a "variable"; instead, it binds
    a name as reference to an object. All functions receive their
    parameters as the existing object with a new name -- a reference to
    that object, just like any other name.


    Hope that helps.

    --
    \ "If you ever teach a yodeling class, probably the hardest thing |
    `\ is to keep the students from just trying to yodel right off. |
    _o__) You see, we build to that." -- Jack Handey |
    Ben Finney
     
    Ben Finney, Jul 13, 2007
    #3
  4. Chris Carlen

    Chris Carlen Guest

    Gabriel Genellina wrote:
    > En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen
    > <> escribió:
    >> http://hetland.org/writing/instant-python.html
    >> I don't understand Hetland's terminology though, when he is speaking of
    >> "binding" and "reference." Actually, Hetland's entire first paragraph
    >> is unclear.

    > First, see this short article http://effbot.org/zone/python-objects.htm


    I'll have a look.

    > Now, forget about C "variables" and "pointers" because you won't get
    > much far with those concepts.


    Ok, painful, but I'll try.

    > Objects exist - and we usually use names to refer to them. This line:
    >
    > a = 1
    >
    > means "make the name 'a' refer to the object 1", or, "bind the name 'a'
    > to the instance of type int with value 1", or "let 'a' be a reference
    > to the object 1"
    >
    > This line:
    >
    > some_list[1] = 4
    >
    > means "make the second element of some_list refer to the object 4", or
    > "alter some_list so its element [1] is a reference to the object 4"
    >
    > bind the name 'a' to the instance of type int with value 1", or "let
    > 'a' be a reference to the object 1"
    >
    > Note that some objects are immutable - like the number 1, which will
    > always be the number 1 (*not* an integer "variable" that can hold any
    > integer value). Other objects -like lists and dictionaries, by example,
    > or most user defined classes- are mutable, and you can change its
    > contents and properties. Modifying an object is not the same as
    > rebinding its name:
    >
    > x = [1,2,3]
    > y = x
    > x[1] = 4
    > print x # [1, 4, 3]
    > print y # [1, 4, 3]


    Thanks to your explanation, I understand!

    > x = [1,2,3]
    > y = x
    > x = [1,4,3]
    > print x # [1, 4, 3]
    > print y # [1, 2, 3]
    >
    > You can test is two names refer to the same object using the is
    > operator: x is y. You will get True in the first case and False in the
    > second case.


    I don't quite get this "x is y" stuff yet.

    Let's go back the statement:

    x = [1,2,3]

    Do we then say: "[1,2,3] is x" or is it the other way around: "x is
    [1,2,3]" ???

    I think it is the former in Python, whereas it would be the latter in C.

    So Python is like saying "I am Chris Carlen."

    This is actually completely ridiculous, since I am me, not my name. The
    name refers to me. I get that. Yet our spoken language puts it in a
    way which is backwards.


    Thanks for the input.





    --
    Good day!

    ________________________________________
    Christopher R. Carlen
    Principal Laser&Electronics Technologist
    Sandia National Laboratories CA USA

    NOTE, delete texts: "RemoveThis" and
    "BOGUS" from email address to reply.
     
    Chris Carlen, Jul 13, 2007
    #4
  5. Chris Carlen

    Chris Carlen Guest

    Ben Finney wrote:
    > Chris Carlen <> writes:
    >
    > def change(some_list):
    > some_list[1] = 4
    >
    > x = [1,2,3]
    > change(x)
    > print x # Prints out [1,4,3]
    > ---
    > def nochange(x):
    > x = 0
    >
    > y = 1
    > nochange(y)
    > print y # Prints out 1
    >
    >>I don't understand Hetland's terminology though, when he is speaking
    >>of "binding" and "reference." Actually, Hetland's entire first
    >>paragraph is unclear.
    >>
    >>Can anyone reword this in a way that is understandable?

    >
    > I've had some success with the following way of thinking about it.
    >
    > Some languages have "variables", which act like boxes that have names
    > etched on the side. Once created, the box can contain an object, and
    > it can be inspected while in the box; to change the variable, you
    > throw out the object and put a different object in the same box.


    Yes, so y = x takes a copy of the stuff in the x box and puts it in the
    y box. Which is what really happens in the hardware.

    > That's not how Python works. Every value is an object; the assignment
    > operator binds a name to an object. This is more like writing the name
    > on a sticky-note, and sticking it onto the object.
    >
    > * The object itself doesn't change or "move".
    >
    > * The object can be referred to by that name, but isn't "inside" the
    > name in any way.
    >
    > * Assigning multiple names to the same object just means you can
    > refer to that same object by all those names.
    >
    > * When a name goes away, the object still exists -- but it can't be
    > referred to if there are no longer any names left on it.
    >
    > * Assigning a different object to an existing name just means that
    > the same sticky-note has moved from the original object to the new
    > one. Referring to the same name now references a different object,
    > while the existing object keeps all the other names it had.


    Excellent description. This understandable to me since I can envision
    doing this with pointers. But I have no idea how Python actually
    implements this. It also appears that I am being guided away from
    thinking about it in terms of internal implementation.

    > When you pass an object as a parameter to a function, the object
    > receives a new sticky-label: the parameter name under which it was
    > received into the function scope. Assignment is an act of binding a
    > name to an object; no new object is created, and it still has all the
    > other names it had before.


    Ok, so I can understand the code above now.

    In the first case I pass the reference to the list to change(). In the
    function, some_list is another name referring to the actual object
    [1,2,3]. Then the function changes the object referred to by the second
    element of the list to be a 4 instead of a 2. (Oh, the concept applies
    here too!) Out of the function, the name x refers to the list which has
    been changed.

    In the second case, y refers to a '1' object and when the function is
    called the object 1 now gets a new reference (name) x inside the
    function. But then a new object '0' is assigned to the x name. But the
    y name still refers to a '1'.

    I get it. But I don't like it. Yet. Not sure how this will grow on me.

    > When the function ends, all the names that were created inside that
    > function's scope disappear; but the objects still exist under any
    > names they had previously, and if you use those names you'll be
    > looking at the same object as was manipulated inside the function.
    >
    > When the object has lost all its names -- for example, they've
    > disappeared because the scope they were in has closed, or they've been
    > re-bound to other objects -- they can no longer be referenced. At some
    > point after that, the automatic garbage collection will clean that
    > object out of memory.
    >
    > This sticky-note analogy, and the behaviour described, is what is
    > meant by "references". A name refers to an object; changing the object
    > means that by referring to that same object under its different names,
    > you will see the same, modified, object.
    >
    > In Python, all names are references to objects. The assignment
    > operator '=' doesn't create or change a "variable"; instead, it binds
    > a name as reference to an object. All functions receive their
    > parameters as the existing object with a new name -- a reference to
    > that object, just like any other name.
    >
    > Hope that helps.



    A great deal of help, thanks. Excellent explanation. Wow. This is
    strange. A part of me wants to run and hide under the nearest 8-bit
    microcontroller. But I will continue learning Python.



    --
    Good day!

    ________________________________________
    Christopher R. Carlen
    Principal Laser&Electronics Technologist
    Sandia National Laboratories CA USA

    NOTE, delete texts: "RemoveThis" and
    "BOGUS" from email address to reply.
     
    Chris Carlen, Jul 13, 2007
    #5
  6. Chris Carlen wrote:
    > Let's go back the statement:
    >
    > x = [1,2,3]
    >
    > Do we then say: "[1,2,3] is x" or is it the other way around: "x is
    > [1,2,3]" ???
    >

    This will yield 'False', because 'is' checks for *identity* not
    equality. In your case you assign a list the name 'x' and then check
    (via the 'is' operator) if it is the same object as another (newly
    created) list. While they are equal (same class and contents) they are
    not the same.
    Try this:

    x = [1, 2, 3]
    y = [1, 2, 3]
    id(x), id(y)
    x == y
    x is y

    Then you'll see.

    > This is actually completely ridiculous, since I am me, not my name. The
    > name refers to me. I get that. Yet our spoken language puts it in a
    > way which is backwards.
    >

    To stress the point: "a is b" has the same meaning as "b is a". It does
    not check for "being a certain thing" (as in "Archimedes is a human")
    but rather for "one thing beeing the exact same as the other" (as in
    "Superman is Clark Kent").
     
    Wildemar Wildenburger, Jul 13, 2007
    #6
  7. Wildemar Wildenburger wrote:
    > x = [1, 2, 3]
    > y = [1, 2, 3]
    > id(x), id(y)
    > x == y
    > x is y
    >

    Ooops!

    Make that:

    x = [1, 2, 3]
    y = [1, 2, 3]
    id(x); id(y)
    x == y
    x is y

    (had to be a semicolon there)
     
    Wildemar Wildenburger, Jul 13, 2007
    #7
  8. Chris Carlen

    Chris Mellon Guest

    On 7/13/07, Chris Carlen <> wrote:
    > Ben Finney wrote:
    > > Chris Carlen <> writes:


    > > That's not how Python works. Every value is an object; the assignment
    > > operator binds a name to an object. This is more like writing the name
    > > on a sticky-note, and sticking it onto the object.
    > >
    > > * The object itself doesn't change or "move".
    > >
    > > * The object can be referred to by that name, but isn't "inside" the
    > > name in any way.
    > >
    > > * Assigning multiple names to the same object just means you can
    > > refer to that same object by all those names.
    > >
    > > * When a name goes away, the object still exists -- but it can't be
    > > referred to if there are no longer any names left on it.
    > >
    > > * Assigning a different object to an existing name just means that
    > > the same sticky-note has moved from the original object to the new
    > > one. Referring to the same name now references a different object,
    > > while the existing object keeps all the other names it had.

    >
    > Excellent description. This understandable to me since I can envision
    > doing this with pointers. But I have no idea how Python actually
    > implements this. It also appears that I am being guided away from
    > thinking about it in terms of internal implementation.
    >


    I assume that you're familiar with the general concept of hash tables.
    Scopes in Python are hash tables mapping strings to Python objects.
    Names are keys into the hash table.

    a = 10

    is the same as
    currentScope["a"] = 10

    print a

    is the same as
    print currentScope["a"]

    As you can see, there's no way that assignment can result in any sort
    of sharing. The only way that changes can be seen between shared
    objects is if they are mutated via mutating methods.

    Python objects (the values in the hashtable) are refcounted and can be
    shared between any scope.

    > > When you pass an object as a parameter to a function, the object
    > > receives a new sticky-label: the parameter name under which it was
    > > received into the function scope. Assignment is an act of binding a
    > > name to an object; no new object is created, and it still has all the
    > > other names it had before.

    >


    Each scope is it's own hashtable. The values can be shared, but not
    the keys. When you call a function, the objects (retrieved from the
    callers local scope by name) are inserted into the functions local
    scope, bound to the names in the function signature. This is what
    Guido calls "call by object reference".



    > Ok, so I can understand the code above now.
    >
    > In the first case I pass the reference to the list to change(). In the
    > function, some_list is another name referring to the actual object
    > [1,2,3]. Then the function changes the object referred to by the second
    > element of the list to be a 4 instead of a 2. (Oh, the concept applies
    > here too!) Out of the function, the name x refers to the list which has
    > been changed.
    >
    > In the second case, y refers to a '1' object and when the function is
    > called the object 1 now gets a new reference (name) x inside the
    > function. But then a new object '0' is assigned to the x name. But the
    > y name still refers to a '1'.
    >
    > I get it. But I don't like it. Yet. Not sure how this will grow on me.
    >


    You need to learn about Pythons scoping now, not it's object passing
    semantics. When you're used to thinking in terms of pointers and
    memory addresses it can take some work to divorce yourself from those
    habits.
     
    Chris Mellon, Jul 13, 2007
    #8
  9. On Fri, 13 Jul 2007 18:49:06 +0200, Wildemar Wildenburger
    <> wrote:

    >Wildemar Wildenburger wrote:
    >> x = [1, 2, 3]
    >> y = [1, 2, 3]
    >> id(x), id(y)
    >> x == y
    >> x is y
    >>

    >Ooops!
    >
    >Make that:
    >
    >x = [1, 2, 3]
    >y = [1, 2, 3]
    >id(x); id(y)
    >x == y
    >x is y
    >
    >(had to be a semicolon there)


    Not "had to be" since a discerning reader will note that the two
    values in the list:

    >>> id(x), id(y)
    (19105872, 19091664)

    are different, and can guess that id() means "address of". But "nicer
    to be" perhaps since it makes it even more clea rto discerning
    readers, and more likely clear to others. ;-)

    >>> id(x); id(y)
    19105872
    19091664

    wwwayne
     
    Wayne Brehaut, Jul 13, 2007
    #9
  10. Chris Carlen

    Steve Holden Guest

    Chris Mellon wrote:
    > On 7/13/07, Chris Carlen <> wrote:
    >> Ben Finney wrote:
    >>> Chris Carlen <> writes:

    >
    >>> That's not how Python works. Every value is an object; the assignment
    >>> operator binds a name to an object. This is more like writing the name
    >>> on a sticky-note, and sticking it onto the object.
    >>>
    >>> * The object itself doesn't change or "move".
    >>>
    >>> * The object can be referred to by that name, but isn't "inside" the
    >>> name in any way.
    >>>
    >>> * Assigning multiple names to the same object just means you can
    >>> refer to that same object by all those names.
    >>>
    >>> * When a name goes away, the object still exists -- but it can't be
    >>> referred to if there are no longer any names left on it.
    >>>
    >>> * Assigning a different object to an existing name just means that
    >>> the same sticky-note has moved from the original object to the new
    >>> one. Referring to the same name now references a different object,
    >>> while the existing object keeps all the other names it had.

    >> Excellent description. This understandable to me since I can envision
    >> doing this with pointers. But I have no idea how Python actually
    >> implements this. It also appears that I am being guided away from
    >> thinking about it in terms of internal implementation.
    >>

    >
    > I assume that you're familiar with the general concept of hash tables.
    > Scopes in Python are hash tables mapping strings to Python objects.
    > Names are keys into the hash table.
    >
    > a = 10
    >
    > is the same as
    > currentScope["a"] = 10
    >
    > print a
    >
    > is the same as
    > print currentScope["a"]
    >
    > As you can see, there's no way that assignment can result in any sort
    > of sharing. The only way that changes can be seen between shared
    > objects is if they are mutated via mutating methods.
    >
    > Python objects (the values in the hashtable) are refcounted and can be
    > shared between any scope.
    >
    >>> When you pass an object as a parameter to a function, the object
    >>> receives a new sticky-label: the parameter name under which it was
    >>> received into the function scope. Assignment is an act of binding a
    >>> name to an object; no new object is created, and it still has all the
    >>> other names it had before.

    >
    > Each scope is it's own hashtable. The values can be shared, but not
    > the keys. When you call a function, the objects (retrieved from the
    > callers local scope by name) are inserted into the functions local
    > scope, bound to the names in the function signature. This is what
    > Guido calls "call by object reference".
    >

    This is, of course, something of an oversimplification. First, the
    global statement allows you to modify a name of module scope from inside
    another scope such as a functions.

    >
    >
    >> Ok, so I can understand the code above now.
    >>
    >> In the first case I pass the reference to the list to change(). In the
    >> function, some_list is another name referring to the actual object
    >> [1,2,3]. Then the function changes the object referred to by the second
    >> element of the list to be a 4 instead of a 2. (Oh, the concept applies
    >> here too!) Out of the function, the name x refers to the list which has
    >> been changed.
    >>
    >> In the second case, y refers to a '1' object and when the function is
    >> called the object 1 now gets a new reference (name) x inside the
    >> function. But then a new object '0' is assigned to the x name. But the
    >> y name still refers to a '1'.
    >>
    >> I get it. But I don't like it. Yet. Not sure how this will grow on me.
    >>

    >
    > You need to learn about Pythons scoping now, not it's object passing
    > semantics. When you're used to thinking in terms of pointers and
    > memory addresses it can take some work to divorce yourself from those
    > habits.


    Then, of course, there are the nested scoping rule for functions defined
    inside other functions.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    --------------- Asciimercial ------------------
    Get on the web: Blog, lens and tag the Internet
    Many services currently offer free registration
    ----------- Thank You for Reading -------------
     
    Steve Holden, Jul 13, 2007
    #10
  11. Wayne Brehaut wrote:
    >> (had to be a semicolon there)
    >>

    >
    > Not "had to be" since a discerning reader will note that the two
    > values in the list:
    >
    > >>> id(x), id(y)
    > (19105872, 19091664)


    Weeeell, as long as we are nitpicking: That's a tuple, not a list.

    ;)
    /W
     
    Wildemar Wildenburger, Jul 14, 2007
    #11
  12. En Fri, 13 Jul 2007 13:41:39 -0300, Chris Carlen
    <> escribió:

    > Ben Finney wrote:
    >> Some languages have "variables", which act like boxes that have names
    >> etched on the side. Once created, the box can contain an object, and
    >> it can be inspected while in the box; to change the variable, you
    >> throw out the object and put a different object in the same box.

    >
    > Yes, so y = x takes a copy of the stuff in the x box and puts it in the
    > y box. Which is what really happens in the hardware.


    At least on some hardware, yes. Python namespaces are more like
    associative memories: you bind a tag (name) to a value, they have constant
    access time... But the real gain comes when you don't have to explicitely
    think step by step on *how* to do things, and can concentrate on a more
    abstract layer and say *what* you want to be done.

    > I get it. But I don't like it. Yet. Not sure how this will grow on me.
    >
    > A great deal of help, thanks. Excellent explanation. Wow. This is
    > strange. A part of me wants to run and hide under the nearest 8-bit
    > microcontroller. But I will continue learning Python.


    I think you will like it in the near future. But for someone coming from
    the microcontroller world, used to think closely in terms of the
    implementation, this may be a big paradigm shift.

    --
    Gabriel Genellina
     
    Gabriel Genellina, Jul 14, 2007
    #12
  13. Chris Carlen

    Ben Finney Guest

    Chris Carlen <> writes:

    > Excellent description. This understandable to me since I can
    > envision doing this with pointers.


    It would be better if you thought in terms of "refrences". Python
    names are unlike pointers in that they don't "store" anything. The
    *only* thing to do with them is refer to an object; don't think of
    them as a C pointer, because Python names don't need to be (and,
    indeed, can't) be "de-referenced".

    > But I have no idea how Python actually implements this. It also
    > appears that I am being guided away from thinking about it in terms
    > of internal implementation.


    Yes. This is a good thing, because Python has multiple implementations
    that are allowed to differ in their internals where it makes sense to
    do so. There are some guarantees at a lower level, that you can find
    in the language reference; but the main advantage of stopping at a
    certain level of abstraction is that the implementation programmers
    are free to *change* the implementation underneath that abstraction
    when it will improve the implementation.

    Meanwhile, the Python programmer is free to work at the abstraction
    level provided by the language, and isn't forced to be always mindful
    of the inner workings if the current implementation.

    --
    \ "To me, boxing is like a ballet, except there's no music, no |
    `\ choreography, and the dancers hit each other." -- Jack Handey |
    _o__) |
    Ben Finney
     
    Ben Finney, Jul 14, 2007
    #13
  14. Chris Carlen a écrit :
    (snip)
    >
    > Excellent description. This understandable to me since I can envision
    > doing this with pointers. But I have no idea how Python actually
    > implements this.


    The code source is freely available, and it's in C !-)

    > It also appears that I am being guided away from
    > thinking about it in terms of internal implementation.


    Indeed. Python *is* a hi-level language, and it's main benefit (wrt to
    lower-level languages like C or Pascal) is to let you think more in
    terms of "what" than in terms of "how".
     
    Bruno Desthuilliers, Jul 14, 2007
    #14
  15. On Sat, 14 Jul 2007 03:18:43 +0200, Wildemar Wildenburger
    <> wrote:

    >Wayne Brehaut wrote:
    >>> (had to be a semicolon there)
    >>>

    >>
    >> Not "had to be" since a discerning reader will note that the two
    >> values in the list:
    >>
    >> >>> id(x), id(y)
    >> (19105872, 19091664)

    >
    >Weeeell, as long as we are nitpicking: That's a tuple, not a list.


    Yeah, just wanted to see if you'd catch it!

    w

    >;)
    >/W
     
    Wayne Brehaut, Jul 14, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xiangliang Meng
    Replies:
    1
    Views:
    1,665
    Victor Bazarov
    Jun 21, 2004
  2. Rensjuh
    Replies:
    7
    Views:
    1,049
    Mabden
    Sep 2, 2004
  3. W. Watson
    Replies:
    13
    Views:
    1,121
    W. Watson
    Sep 20, 2007
  4. Linuxmank
    Replies:
    36
    Views:
    1,551
    Linuxmank
    Aug 8, 2009
  5. Curt Hibbs
    Replies:
    0
    Views:
    120
    Curt Hibbs
    Feb 3, 2006
Loading...

Share This Page