Re: anything like C++ references?

Discussion in 'Python' started by David McNab, Jul 13, 2003.

  1. David McNab

    David McNab Guest

    On Sat, 12 Jul 2003 13:53:35 -0700, Tom Plunket paused, took a deep
    breath, then came out with:

    > I want to do something along the lines of the following C++ code:
    >
    > void change(int& i)
    > {
    > i++;
    > }


    > Is there any way to do references like this in Python?

    <snip>

    In Python, basic types like strings and numbers are a weird exception to
    the 'everything is an object' rule.

    When you pass any other object in a function, the function gets a ref to
    that object.

    But when you pass a string or numeric object, the whole thing (not a ref)
    gets passed.

    Your best bet would be to create a wrapper class for numbers, store the
    actual number in an attribute, and provide all the methods in Section
    3.3.6 of the Python Reference Manual (__add__, __sub__ etc) to work on the
    value attribute.

    That way, you can use your numeric object in calculations, and when you
    pass it to functions (like your 'change()' above), things will work as
    expected. In fact, in most situations, it will look/feel/smell just like
    a number.

    But watch out for trying to assign to it, or using '+=' type operators -
    they will replace your object with a plain number.

    I attach below a sample class declaration for a numeric type which is
    passable by reference (no need to do this for string, since you can just
    use the UserString module).

    Cheers
    David

    class myint:
    def __init__(self, value):
    self.value = value

    def __getattr__(self, attr):
    if attr in ['__repr__', '__add__', '__repr__', '__add__',
    '__sub__', '__mul__', '__floordiv__', '__mod__',
    '__divmod__', '__pow__', '__lshift__',
    '__rshift__', '__and__', '__xor__', '__or__',
    '__div__', '__truediv__', '__radd__', '__rsub__',
    '__rmul__', '__rdiv__', '__rtruediv__',
    '__rfloordiv__', '__rmod__', '__rdivmod__',
    '__rpow__', '__rlshift__', '__rrshift__',
    '__rand__', '__rxor__', '__ror__',
    '__neg__',
    '__pos__', '__abs__', '__invert__',
    '__complex__', '__int__', '__long__',
    '__float__', '__oct__', '__hex__', '__coerce__']:
    return getattr(self.value, attr)

    def __iadd__(self, other):
    self.value += other
    return self.value

    def __isub__(self, other): self.value -= other
    def __imul__(self, other): self.value *= other
    def __idiv__(self, other): self.value /= other
    def __itruediv__(self, other):
    self.value = self.value.__itruediv__(other)
    def __ifloordiv__(self, other): self.value = self.value.__itruediv__(other)
    def __imod__(self, other): self.value = self.value.__imod__(other)
    def __ipow__(self, other): self.value = self.value.__ipow__(other)
    def __ilshift__(self, other): self.value = self.value.__ilshift__(other)
    def __irshift__(self, other): self.value = self.value.__irshift__(other)
    def __iand__(self, other): self.value = self.value.__iand__(other)
    def __ixor__(self, other): self.value = self.value.__ixor__(other)
    def __ior__(self, other): self.value = self.value.__ior__(other)
     
    David McNab, Jul 13, 2003
    #1
    1. Advertising

  2. David McNab

    Oren Tirosh Guest

    On Sun, Jul 13, 2003 at 10:58:13PM +1200, David McNab wrote:
    > On Sat, 12 Jul 2003 13:53:35 -0700, Tom Plunket paused, took a deep
    > breath, then came out with:
    >
    > > I want to do something along the lines of the following C++ code:
    > >
    > > void change(int& i)
    > > {
    > > i++;
    > > }

    >
    > > Is there any way to do references like this in Python?

    > <snip>
    >
    > In Python, basic types like strings and numbers are a weird exception to
    > the 'everything is an object' rule.
    >
    > When you pass any other object in a function, the function gets a ref to
    > that object.
    >
    > But when you pass a string or numeric object, the whole thing (not a ref)
    > gets passed.


    Numbers and strings are objects just like everything else in Python and
    are passed by reference. The only difference is that they are *immutable*
    objects so their value cannot be changed through that reference in a way
    that will be visible to others who reference the same object. Under most
    circumstances a reference to an immutable object is nearly indistingishable
    from a value. But the id() builtin function or the 'is' operator quickly
    reveal the difference.

    There is no weird exception to any rule here. Some objects are mutable,
    some are not. That's all.

    Oren
     
    Oren Tirosh, Jul 13, 2003
    #2
    1. Advertising

  3. David McNab

    Terry Reedy Guest

    "David McNab" <postmaster@127.0.0.1> wrote in message
    news:pan.2003.07.13.10.58.11.376531@127.0.0.1...
    > In Python, basic types like strings and numbers are a weird

    exception to
    > the 'everything is an object' rule.


    In Java perhaps, but NOT in Python. This is WRONG, WRONG, WRONG.
    Please do not muddy the waters like this.

    In Python, most builtin types are immutable. The two mutable builtin
    types are lists and dicts. Instances of user-defined classes are also
    mutable by default.

    >When you pass any other object in a function,
    >But when you pass a string or numeric object, [incorrect statement

    clipped]

    In Python, everything is 'passed' to functions the same way: first,
    the argument expressions are evaluated one at a time, left to right.
    In the typical case (number of argument expressions == number of
    positional parameters), the resulting objects are then bound to the
    corresponding parameter names, left to right, in the local namespace
    of the function. (Or, if you prefer, the names are bound ...) The
    type of the argument objects is not looked at.

    How a particular interpreter performs name binding is its own
    business, as long as the specified semantics are implemented. What
    CPython does may or may not be the same as Jython or any other actual
    or potential computer implementation. What any computer does is
    probably significantly different from what human interpreters do.

    Terry J. Reedy
     
    Terry Reedy, Jul 13, 2003
    #3
  4. David McNab

    Ian Bicking Guest

    On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
    > The fact is that 'assignment' has a common meaning separate from the
    > choice of programming language,


    This just isn't true. The C++ assignment operator is not at all like
    the Python assignment statement. Python variables are not like C++
    variables, no surprise assignment is different too. If you used
    languages outside of C++ and its like (e.g., Pascal), you would find
    Python's behavior common.

    (Admittedly, some confusion may occur because these very different
    operations use the same syntax:

    x = 10
    x[0] = 10
    obj.x = 10

    The second and third are entirely different from the first.)

    Ian
     
    Ian Bicking, Jul 13, 2003
    #4
  5. David McNab wrote:

    > In Python, basic types like strings and numbers are a weird exception to
    > the 'everything is an object' rule.
    >
    > When you pass any other object in a function, the function gets a ref to
    > that object.
    >
    > But when you pass a string or numeric object, the whole thing (not a ref)
    > gets passed.



    This is completely incorrect. On the contrary, builtin types are
    handled exactly uniformly in Python. The only difference here is that
    the builtin types that you've listed, along with some others, are
    immutable, so you cannot change them if you have a reference to them.

    Contrast this to, say, Java, where there really is a solid distinction
    between builtin fundamental types, like int and long, and actual object
    types, derived from java.lang.Object, which are all passed by reference.
    Python doesn't make this distinction.


    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ But who shall dwell in these worlds if they be inhabited?
    \__/ Johannes Kepler
     
    Erik Max Francis, Jul 13, 2003
    #5
  6. David McNab

    Terry Reedy Guest

    "Stephen Horne" <> wrote in message
    news:...
    > On Sun, 13 Jul 2003 15:07:23 -0400, "Terry Reedy" <>
    > wrote:
    >
    > >How a particular interpreter performs name binding is its own
    > >business, as long as the specified semantics are implemented.

    >
    > You could use the same argument to rationalise a language which used
    > the + operator to express subtraction.


    Bogus comparison with name binding. I am not aware that Python does
    anything quite so backwards.

    > The fact is that 'assignment' has a common meaning separate from the
    > choice of programming language, and that the way Python handles name
    > binding means that meaning is not respected by Python for mutable
    > objects.


    From what others have posted, Python is not the only language in which
    'name=object' means "assign 'name' to that object". This is much
    closer to the common idea of object having names than the idea that
    names can only name value holders (blocks of linear memory) and not
    values or objects themselves.

    Terry J. Reedy
     
    Terry Reedy, Jul 13, 2003
    #6
  7. On Sun, Jul 13, 2003 at 03:05:38PM -0500, Ian Bicking wrote:
    > On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
    > > The fact is that 'assignment' has a common meaning separate from the
    > > choice of programming language,

    >
    > This just isn't true. The C++ assignment operator is not at all like
    > the Python assignment statement. Python variables are not like C++
    > variables, no surprise assignment is different too. If you used
    > languages outside of C++ and its like (e.g., Pascal), you would find
    > Python's behavior common.
    >


    C++ is the only language that has the same semantics as C++.

    I was a long time C++ guy and my a-ha moment was when I realized that the
    GoF's "Design Patterns" were not all universal -- some are C++ specific.
    Trying to force Python semantics into a C++ world view will leave you feeling
    empty every time. Drink the koolaid, python has a short learning curve.
    If this is a problem - whatever you do - DONT TRY TO LEARN LISP.

    If you want a more polished C++, use Java. Python is in a different class
    of languages.

    -jack
     
    Jack Diederich, Jul 13, 2003
    #7
  8. On 13 Jul 2003 15:05:38 -0500, Ian Bicking <>
    wrote:

    >On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
    >> The fact is that 'assignment' has a common meaning separate from the
    >> choice of programming language,

    >
    >This just isn't true. The C++ assignment operator is not at all like
    >the Python assignment statement. Python variables are not like C++
    >variables, no surprise assignment is different too. If you used
    >languages outside of C++ and its like (e.g., Pascal), you would find
    >Python's behavior common.


    Think again.

    When I say "'assignment' has a common meaning separate from the choice
    of programming language" I assumed you would get the hint. I'm not
    referring to some specific other programming language, of which I have
    used many - and not all of them imperative. I am referring to the
    definitions in computer theory, which do not relate to any specific
    programming language but actually apply to all of them, irrespective
    of paradigm and everything else.

    Of course, if you really believe that pointer/reference behaviour
    should be arbitrarily tied to mutability then you can claim that I am
    wrong, but you still can't claim the high ground as this is still an
    arbitrary and bizarre thing to do. The ability to change part or all
    of a value in-place has nothing to do with whether that value is
    referenced using a pointer or whatever in computer theory - any link
    between pointers/references and mutability should be related to the
    implementation of the language - not the semantics.

    So much for dropping out of the discussion, but I hate it when people
    make false claims about my beliefs, making me out to be ignorant, when
    it is *not* *me* who is missing the point.
     
    Stephen Horne, Jul 13, 2003
    #8
  9. On Sun, 13 Jul 2003 17:16:08 -0400, "Terry Reedy" <>
    wrote:

    >> You could use the same argument to rationalise a language which used
    >> the + operator to express subtraction.

    >
    >Bogus comparison with name binding. I am not aware that Python does
    >anything quite so backwards.


    Using an exaggeration as an analogy. Possibly. Though terms like
    'assignment', 'variable' and 'value' seems pretty fundamental to me,
    so the exaggeration is not that huge.

    >> The fact is that 'assignment' has a common meaning separate from the
    >> choice of programming language, and that the way Python handles name
    >> binding means that meaning is not respected by Python for mutable
    >> objects.

    >
    >From what others have posted, Python is not the only language in which
    >'name=object' means "assign 'name' to that object". This is much
    >closer to the common idea of object having names than the idea that
    >names can only name value holders (blocks of linear memory) and not
    >values or objects themselves.


    Many languages have *explicit* ways to create what computer science
    calls pointers. Sometimes they have implicit dereferencing. Sometimes
    they come prepackaged in a 'pointer to' or 'reference to' style
    object. But the fact that you are dealing with something that
    semantically behaves as a pointer is always explicit in some way or
    another.

    Or rather, it should be. The fact that a few other languages are
    broken in much the same way does not mean that Python is doing the
    right thing. The right thing does not mean imitating Java or whatever
    any more than it means imitating C++.

    If you want a good example to imitate, though, look to Haskell. I
    don't know how it binds variables to values, but I do know that in
    general it can't a simple mapping from identifier to memory location.
    Even so, I don't care. Why should I? The implementation of the binding
    is irrelevant - I only care that the value bound to the variable is
    the one that I specified and that it doesn't get changed behind my
    back.
     
    Stephen Horne, Jul 13, 2003
    #9
  10. Stephen Horne <> writes:

    > >This just isn't true. The C++ assignment operator is not at all like
    > >the Python assignment statement. Python variables are not like C++
    > >variables, no surprise assignment is different too. If you used
    > >languages outside of C++ and its like (e.g., Pascal), you would find
    > >Python's behavior common.

    [...]
    > The ability to change part or all
    > of a value in-place has nothing to do with whether that value is
    > referenced using a pointer or whatever in computer theory - any link
    > between pointers/references and mutability should be related to the
    > implementation of the language - not the semantics.


    So you think "assignment" is about "changing values"? This is the case
    in C and C++, but not the case in Java (atleast for objects), and Python.

    In Python, assignment changes variables, not values. This is something
    fundamentally different. In Python (and many other languages),
    variables are independent of their value (and vice versa). Variables
    are *associated* with a value, instead of *being* that value. Then,
    assignment changes that association - not the value itself.

    > So much for dropping out of the discussion, but I hate it when people
    > make false claims about my beliefs, making me out to be ignorant, when
    > it is *not* *me* who is missing the point.


    I'm uncertain what your point is, however, I do observe that computer
    theory has a different view of what assignments are than what I think
    your view is.

    Regards,
    Martin
     
    Martin v. =?iso-8859-15?q?L=F6wis?=, Jul 13, 2003
    #10
  11. Erik Max Francis <> writes:

    > This is completely incorrect. On the contrary, builtin types are
    > handled exactly uniformly in Python. The only difference here is that
    > the builtin types that you've listed, along with some others, are
    > immutable, so you cannot change them if you have a reference to them.


    All you guys must be forgetting:

    >>> a = [1]
    >>> b = a
    >>> a += b
    >>> assert id(a) == id(b)
    >>> a = 1
    >>> b = a
    >>> a += b
    >>> assert id(a) == id(b)

    Traceback...

    --
    Dave Abrahams
    Boost Consulting
    www.boost-consulting.com
     
    David Abrahams, Jul 14, 2003
    #11
  12. David McNab

    Aahz Guest

    In article <>,
    Terry Reedy <> wrote:
    >
    >In Python, most builtin types are immutable. The two mutable builtin
    >types are lists and dicts. Instances of user-defined classes are also
    >mutable by default.


    Actually, files are mutable, too. Then again, so are modules. And
    functions. Gee, there are an awful lot of built-in mutable types. ;-)
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Not everything in life has a clue in front of it...." --JMS
     
    Aahz, Jul 14, 2003
    #12
  13. David McNab

    Aahz Guest

    In article <>,
    Ian Bicking <> wrote:
    >
    >(Admittedly, some confusion may occur because these very different
    >operations use the same syntax:
    >
    > x = 10
    > x[0] = 10
    > obj.x = 10
    >
    >The second and third are entirely different from the first.)


    No, they aren't. They are precisely the same; they just have different
    assignment targets.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Not everything in life has a clue in front of it...." --JMS
     
    Aahz, Jul 14, 2003
    #13
  14. David McNab

    Aahz Guest

    In article <>,
    Stephen Horne <> wrote:
    >
    >In Python, Guido describes his rationale for the existence of both
    >mutable lists and immutable tuples here...
    >
    >http://www.python.org/search/hypermail/python-1992/0292.html


    I'll note that Guido himself has also admitted that his ability to
    explain his design decisions is far worse than his ability to select a
    correct decision. These days, the rationale for tuples is that they're
    a hyper-lightweight collection of heterogeneous values.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Not everything in life has a clue in front of it...." --JMS
     
    Aahz, Jul 14, 2003
    #14
  15. David McNab

    Aahz Guest

    In article <>,
    David Abrahams <> wrote:
    >Erik Max Francis <> writes:
    >>
    >> This is completely incorrect. On the contrary, builtin types are
    >> handled exactly uniformly in Python. The only difference here is that
    >> the builtin types that you've listed, along with some others, are
    >> immutable, so you cannot change them if you have a reference to them.

    >
    >All you guys must be forgetting:
    >
    > >>> a = [1]
    > >>> b = a
    > >>> a += b
    > >>> assert id(a) == id(b)
    > >>> a = 1
    > >>> b = a
    > >>> a += b
    > >>> assert id(a) == id(b)

    > Traceback...


    I'm not forgetting that. It's an unfortunate and tricky part of Python
    semantics in some respects, but it's easily explained and understood if
    you focus on the objects rather than the operation:

    a = foo
    b = a
    a = a.__iadd__(b)

    Where id(a)==id(b) depends solely on the behavior of __iadd__().
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Not everything in life has a clue in front of it...." --JMS
     
    Aahz, Jul 14, 2003
    #15
  16. On 13 Jul 2003 21:30:54 -0400, (Aahz) wrote:

    >In article <>,
    >Terry Reedy <> wrote:
    >>
    >>In Python, most builtin types are immutable. The two mutable builtin
    >>types are lists and dicts. Instances of user-defined classes are also
    >>mutable by default.

    >
    >Actually, files are mutable, too. Then again, so are modules. And
    >functions. Gee, there are an awful lot of built-in mutable types. ;-)


    True. Damn. 'Boneheaded' is definitely my thing, today.
     
    Stephen Horne, Jul 14, 2003
    #16
  17. David McNab

    Donn Cave Guest

    On Sun, 2003-07-13 at 20:32, Aahz wrote:
    > In article <>,

    |> Ian Bicking <> wrote:
    |>>
    |>> (Admittedly, some confusion may occur because these very different
    |>> operations use the same syntax:
    |>>
    |>> x = 10
    |>> x[0] = 10
    |>> obj.x = 10
    |>>
    |>> The second and third are entirely different from the first.)
    |>
    |> No, they aren't. They are precisely the same; they just have different
    |> assignment targets.
    |
    | Sure they are different. The first is a primitive operation binding the
    | variable x. The second gets x, and calls x.__setitem__(0, 10), and the
    | third is equivalent to setattr(obj, 'x', 10).

    I wonder if this is a good example of a mutability thing that really
    is kind of missing to the detriment of Python.

    If you want to support user-implemented sequences (as Python does)
    but make Aahz's ``precisely the same'' assertion true in the sense
    you're taking it - then I think the user-implemented indexing function
    would have to return a reference to the index location.

    class UserArray:
    ...
    def __item__(self, index):
    return &self.internal_array[index]

    userArray[5] = 1
    (python internal)
    loc = UserArray.__item__(userArray, 5)
    *loc = 1

    if userArray[6] ==
    (python internal)
    loc = UserArray.__item__(userArray, 6)
    return *loc

    There are other places where instead we use some kludge with a
    mutable container type, but in this case I don't think there's
    a way to get around it. So whether we like the idea or not,
    assignment to a user-implemented sequence doesn't have to involve
    any assignment at all, because Python lacks the "pointer" type
    (or "target" type, if you prefer) that would be required to
    implement that.

    Donn Cave,
     
    Donn Cave, Jul 14, 2003
    #17
  18. David McNab

    Aahz Guest

    In article <>,
    Ian Bicking <> wrote:
    >On Sun, 2003-07-13 at 20:32, Aahz wrote:
    >> In article <>,
    >> Ian Bicking <> wrote:
    >>>
    >>>(Admittedly, some confusion may occur because these very different
    >>>operations use the same syntax:
    >>>
    >>> x = 10
    >>> x[0] = 10
    >>> obj.x = 10
    >>>
    >>>The second and third are entirely different from the first.)

    >>
    >> No, they aren't. They are precisely the same; they just have different
    >> assignment targets.

    >
    >Sure they are different. The first is a primitive operation binding the
    >variable x. The second gets x, and calls x.__setitem__(0, 10), and the
    >third is equivalent to setattr(obj, 'x', 10).
    >
    >The first is primitive syntax. I suppose you could say that it could be
    >reduced to operations on locals() and globals(), but I feel like that's
    >a detail that is best not brought up ;) The local and global scope are
    >not as flexible as other objects The other two are really just syntactic
    >sugar.


    You've got a good point, but I think my point is just as valid. Which
    viewpoint is more appropriate depends on the circumstance.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Not everything in life has a clue in front of it...." --JMS
     
    Aahz, Jul 14, 2003
    #18
  19. On Mon, 14 Jul 2003 03:40:05 -0000, "Donn Cave" <> wrote:

    >On Sun, 2003-07-13 at 20:32, Aahz wrote:
    >> In article <>,

    >|> Ian Bicking <> wrote:
    >|>>
    >|>> (Admittedly, some confusion may occur because these very different
    >|>> operations use the same syntax:
    >|>>
    >|>> x = 10
    >|>> x[0] = 10
    >|>> obj.x = 10
    >|>>
    >|>> The second and third are entirely different from the first.)
    >|>
    >|> No, they aren't. They are precisely the same; they just have different
    >|> assignment targets.
    >|
    >| Sure they are different. The first is a primitive operation binding the
    >| variable x. The second gets x, and calls x.__setitem__(0, 10), and the
    >| third is equivalent to setattr(obj, 'x', 10).

    Which might turn out to be equivalent to object.__setattr__(obj, 'x', 10)
    or obj.__setattribute__('x', 10) or obj.__class__.__dict__['x'].fset(obj, 10) or ...

    It depends on what you mean by 'targets'. I argued that the three left hand
    expressions all *ultimately* result in some machine level pointer variable being set
    in some object's internal representation to point to the representation of the object
    resulting from evaluating the right hand side, and in that sense all the assignments
    have the same ultimate semantics. Some pointer in some composite object is set to point
    to another object.

    Depending on the left hand object actually involved, we use different expressions to
    retrieve the pointer (and often you have a choice, e.g., x.y or x.__dict__['y'] or getattr(x,'y')
    or vars(x).get('y') etc., some of which might not be valid. Even plain x might sometimes be
    retrieved by sys._getframe().f_locals.get('x').

    >
    >I wonder if this is a good example of a mutability thing that really
    >is kind of missing to the detriment of Python.
    >
    >If you want to support user-implemented sequences (as Python does)
    >but make Aahz's ``precisely the same'' assertion true in the sense
    >you're taking it - then I think the user-implemented indexing function
    >would have to return a reference to the index location.
    >


    I guess you could define something like your *loc below, but you'd have to be
    willing to spell it loc.star when you used it.

    class Loc(object): #XXX# untested !!
    def __init__(self, theArray, theItem=0): self._theArray=theArray; self._theItem=theItem
    def _get_it(self): return self._theArray[self._theItem]
    def _set_it(self,v): self._theArray[self._theItem] = v
    star = property(_get_it, _set_it)

    > class UserArray:
    > ...
    > def __item__(self, index):

    return Loc(self, index)
    > return &self.internal_array[index]
    >
    > userArray[5] = 1
    > (python internal)
    > loc = UserArray.__item__(userArray, 5)

    loc.star = 1
    > *loc = 1
    >
    > if userArray[6] ==
    > (python internal)
    > loc = UserArray.__item__(userArray, 6)

    return loc.star
    > return *loc
    >
    >There are other places where instead we use some kludge with a
    >mutable container type, but in this case I don't think there's
    >a way to get around it. So whether we like the idea or not,
    >assignment to a user-implemented sequence doesn't have to involve
    >any assignment at all, because Python lacks the "pointer" type
    >(or "target" type, if you prefer) that would be required to
    >implement that.


    Or you could say the implementation is internal and you have
    to use the right spellings to effect the semantics indirectly.
    I.e., op=newitem spells *p = newitem internally (names obviously not directly related):

    int
    PyList_SetItem(register PyObject *op, register int i,
    register PyObject *newitem)
    {
    ...
    p = ((PyListObject *)op) -> ob_item + i;
    olditem = *p;
    *p = newitem;
    Py_XDECREF(olditem);
    return 0;
    }

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 14, 2003
    #19
  20. On Sun, 13 Jul 2003 22:20:33 +0100, rumours say that Stephen Horne
    <> might have written:

    >On 13 Jul 2003 15:05:38 -0500, Ian Bicking <>
    >wrote:
    >
    >>On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:


    >>> The fact is that 'assignment' has a common meaning separate from the
    >>> choice of programming language,


    >>This just isn't true. The C++ assignment operator is not at all like
    >>the Python assignment statement. Python variables are not like C++
    >>variables, no surprise assignment is different too. If you used
    >>languages outside of C++ and its like (e.g., Pascal), you would find
    >>Python's behavior common.

    >
    >Think again.
    >
    >When I say "'assignment' has a common meaning separate from the choice
    >of programming language" I assumed you would get the hint. I'm not
    >referring to some specific other programming language, of which I have
    >used many - and not all of them imperative. I am referring to the
    >definitions in computer theory, which do not relate to any specific
    >programming language but actually apply to all of them, irrespective
    >of paradigm and everything else.


    [and snip of various other stuff]

    perhaps I am too late, and off subject at this point in time, but I
    believe I can offer something to the discussion; I just picked to follow
    up a post that looked appropriate for my digression below.



    The way I see it, practically, there are two ways to describe the python
    variables/names, and it comes down to choosing labels (nb. the following
    paragraphs are valid for CPython, and do not take account of other
    computer languages or computer science in general):

    - if you choose the labels 'name', 'object', 'binding' as most
    pythonistas do, then the python assignment operator 'binds' 'names' to
    'objects'. You can't 'bind' 'names' to 'names', since they are not
    'objects'.
    The function id() returns the identity of the 'object' 'bound' to
    'name'.
    Argument passing is neither 'call by reference' or 'call by value'; it's
    something one can name 'call by object'.

    - if you choose the labels 'variable', 'value', 'reference', 'object',
    then *all* 'variables' are of the same type: 'reference' to 'object'. A
    'variable' is not a python 'object', so you can't have one 'variable'
    'referencing' another 'variable'. You can't store an 'object' to a
    'variable', just a 'reference' to the 'object'.
    The function id() returns the 'value' of the 'variable'.
    In this case, all argument passing is "call by value"; all 'values' are
    'references' to 'objects'.



    Please note that a python 'name' (or a python 'variable') is completely
    described by the following regular expression:

    ^[_A-Za-z][_A-Za-z0-9]*$

    So you are certain that you are 'binding' a 'name' to an 'object' (or
    storing the 'reference' to an 'object' in a 'variable') only when you
    have something like the following:

    name = <any valid python expression>

    This is *always* an assignment operation. You can't control it with
    specially-named functions (something like __assign__, say). If you are
    of the 'variable', 'value' persuasion, then most of the time the 'value'
    of "name" changes by the assignment operation, even if the new 'object'
    is equal to the old 'one'.

    OTOH, if you have something like:

    another_name.name = <any valid python expression>

    then the LHS is not a 'name' (or a 'variable'). It's the "name"
    attribute (or property) of the "another_name" object. This code can
    call several python functions, depending on the type/class of
    "another_name". The execution of the above statement might invoke some
    methods of the 'object' presently known as "another_name" (eg
    __setattr__ or a special property put method).
    The "name" attribute can be a 'name' (or a 'variable'), but it's not
    necessarily so.



    This post is a good example of bad writing, but the ways of
    enlightenment are obscure... ;-)
    --
    TZOTZIOY, I speak England very best,
    Microsoft Security Alert: the Matrix began as open source.
     
    Christos TZOTZIOY Georgiou, Jul 18, 2003
    #20
    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. Ian Bicking

    RE: anything like C++ references?

    Ian Bicking, Jul 12, 2003, in forum: Python
    Replies:
    54
    Views:
    1,111
    Christos TZOTZIOY Georgiou
    Jul 22, 2003
  2. Dave Brueck

    Re: anything like C++ references?

    Dave Brueck, Jul 13, 2003, in forum: Python
    Replies:
    4
    Views:
    368
    =?ISO-8859-1?Q?Hannu_Kankaanp=E4=E4?=
    Jul 14, 2003
  3. Tim Peters

    RE: anything like C++ references?

    Tim Peters, Jul 13, 2003, in forum: Python
    Replies:
    44
    Views:
    1,057
    Tim Roberts
    Jul 20, 2003
  4. Michael Chermside

    RE: anything like C++ references?

    Michael Chermside, Jul 14, 2003, in forum: Python
    Replies:
    2
    Views:
    282
    Michael Hudson
    Jul 15, 2003
  5. Replies:
    5
    Views:
    327
    Stephen Horne
    Jul 17, 2003
Loading...

Share This Page