Odd behavior regarding a list

[Edd Barrett]

Hi there,

My first post here, so hello :)

Just a little background, I am writing my dissertation, which is a JIT
compiler based upon LLVM and it's python bindings, along with the
aperiot LL(1) parser.

I have some code here, which is not behaving as I would expect. Could
someone enlighten me as to why this is so:

---8<---
def __classdef_integer(self):
"""
class definition for a integer object.
"""

this_class = "Integer"

# metadata inherited
self.__class_data[this_class] = \
self.__class_data["Object"]

# cache parent struct sig for later (when casting ptrs)
parent_struct_sig = \
self.__class_data[this_class]["struct-sig"]

this_cdata = self.__class_data[this_class]
#this_cdata["membernames"].append("value")
#this_cdata["type-sym"] = 1
#this_cdata["parent-class"] = "Object"

#vtab = self.__construct_vtable(this_class)
#self.__ir_add_typesym(this_class, vtab)


print "parent"
print parent_struct_sig
this_cdata["struct-sig"].append(self.__int_t)
print "new"
print parent_struct_sig

sys.exit(1)
 ---8<---

Notice how I am caching the old value of 'parent_struct_sig' before I
manipulate it.

Produces the following output:

---8<---
parent
[]
new
[, ]
---8<---

My question is: why has 'parent_struct_sig' changed? I was under the
impression the assignment operator copies, not references.

Sorry if the answer is blindingly obvious. I am somewhat jaded from
working on this every day :P

Heres my python environment:
---8<---
Python 2.6.1 (r261:67515, Dec 27 2008, 16:56:14)
[GCC 4.2.0 20070307 (prerelease)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
---8<---

Thanks
--
http://mail.python.org/mailman/listinfo/python-list

Re: Odd behavior regarding a list

[Edd Barrett]

Hi there,

First of all, thanks to everyone for replying. This has been a great
help.

On Mar 26, 4:21 pm, Steven D'Aprano  wrote:
> On Thu, 26 Mar 2009 08:36:49 -0700, Edd Barrett wrote:
> > My question is: why has 'parent_struct_sig' changed? I was under the
> > impression the assignment operator copies, not references.
>
> You are mistaken. Firstly, Python does not have an assignment operator.
> Assignment (technically, name binding) is not an operator in Python. You
> can't over-ride it.
>
> Secondly, assignment in Python *never* copies. Ever. The only time a copy
> is made is when you explicitly ask for a copy.

This explains it.

>
> e.g. to copy a list L, use one of:
>
> list(L)
>
> L[:]

Great :)


> A few more comments, based on your code.
>
> >    def __classdef_integer(self):
>
> Double-underscore name mangling is often more trouble than it is worth.
> Unless you really need it, not just think you will need it, it is
> generally considered poor style.

It was an attempt at encapsulation. I didn't want my parser to call
internals willy-nilly.  Is there a better way?

>
> ...
>
> >            # cache parent struct sig for later (when casting ptrs)
>
> If you're actually casting pointers in your code, I don't know what
> language you're using, but it isn't Python! Python is not C, you don't
> have direct access to pointers. I don't know what you're doing, perhaps
> the comment is misleading?

This is not reffering to anything python :P
I will be casting some pointer types in LLVM assembler. Python is
going to generate this code.

>
> ...
>
> >            sys.exit(1)
>
> You do realise that this line tells your program to exit? Seems like a
> strange thing to include in a method.

I'm just debugging this part of code. Obviously this is removed now.

> Hope some of this is helpful.

Very! Many thanks.


--

Edd

--
http://mail.python.org/mailman/listinfo/python-list